-
Notifications
You must be signed in to change notification settings - Fork 80
Issues with packaging browserpass for Debian #245
Comments
Check the developer console for both the popup window, and the background page. Do you see an error message in the console? |
Not sure if I used it correctly, but I do see this: TypeError: Cannot read property 'autoSubmit' of undefined Whether I have auto submit configured or not does not make a difference. |
Do you see in which file this happens, maybe even a line number? I suspect it's this line: |
@maximbaz I haven't been able to reproduce this issue, but the line you've flagged is an issue - it's trying to access an object which may sometimes be uninitialised. I've just opened PR #246 to ensure that the settings are always present - I don't know whether that's enough to fix this bug, as I've not been able to reproduce it here. |
Current master works a little bit longer. If I access e.g. github it now shows me my github entry, but as soon as I click on it I get the neverending circle again. New error message is: content.html:1 Error in event handler for (unknown): TypeError: Cannot read property 'error' of undefined The line in questions is the "if (response.error)" in function getLoginData() { chrome.runtime.sendMessage( |
Hmm, something is very wrong with your extension. Just curious, does it reproduce with extension in the webstore? Could you try to clone the repo from scratch, and then build the extension with |
No, it does not. I'm working on the Debian package for it and am trying to figure out why it worked correctly with 2.0.11 and 2.0.13 but not with 2.0.18. The build process is different because Debian does not have browserify, but only browserify-lite. I cannot see any functional differences in the js files, though. Also, I did try copying the 2.0.18 files from firefox.zip to the location the package resides in, to no avail, some problem. However, this obviously was before the patch. |
Are you able to explain how you have changed the build process? If the 'official' builds are working, but yours is not, that might give us a clue as to where the problem might be. If a reference would be helpful, I can confirm that builds via docker (see CONTRIBUTING.md) are working correctly against the current master. |
@meskes One other thing that may be relevant if you're building the browserify bits differently: as of 2.0.18, |
The sources are in https://salsa.debian.org/webext-team/browserpass The makefile is debian/rules. Chances are I missed something, but then why didn't copying the files from the zip file help? |
The makefile seems OK. I'll try building from your sources and see what happens, hang on. |
I can confirm that building from the master branch of the debian repo you have linked above works normally, and results in a usable extension. However, there is a unit test failure when building the host app, and that failure is also present for the master branch of this repo - I've opened #248 for this. If you run the 2.0.18 browser extension that you have built, but use the host app binary from the github release, does it work correctly?
|
Nope, same effect. Hmm, it seems like you build from my source but not with my makefile, right? |
I built using the default makefile (i.e. the makefile from the master branch root). Does yours live elsewhere? |
Unit test fails because it cannot retrieve the "current user" in the docker environment, I don't think that is relevant to this issue. @meskes in order not to deal with browserify or other dependencies, just grab the |
@meskes I've diffed your master against 2.0.18 of this repo - the only difference is the presence of a Could you please advise how you're building this? |
@erayd you missed above:
|
Oops - I did indeed miss that. Thanks :-). |
Here you go, based on the current master: release.zip |
this seems to work, let's see where the difference is ... |
It seems to be background.js |
It became to be "browserified" only recently 😉 So... problem solved? P.S. Will you please submit a PR to the README.md when it will be possible for Debian users to install browserpass via official package management tools? |
@maximbaz Might be worth rolling 2.0.19, if the changes in master have solved a packaging problem. That way the debian package version will be properly in sync with the repo release tags. Otherwise if someone reports a problem, and the debian version of 2.0.18 contains more than what's actually in the 2.0.18 release... |
Will do once @meskes confirms that the issue is solved and this ticket can be closed 👍 |
@maximbaz problem is not solved, I just noticed that it works with your background.js but not with mine, why is a different matter As for the package, it is already available since 2.0.11, but I can surely do a PR for that |
|
browserify-lite If it's just browserify-lite that's not working correctly, it's not an issue here, but if it's coming from someplace else ... |
Just curious, why not use pre-generated sources and avoid having troubles with browserify and other dependencies alltogether? It is also a burden for you to maintain, for example a week ago |
The idea behind this is to compile everything from sources and by doing so getting the latest version of the dependencies as well. |
That's not very good, we have yarn.lock and Gopkg.lock to make sure everyone is using the same versions of everything to avoid issues that cannot be reproduced by everyone. If a dependency needs to be updated, I'd much prefer seeing a PR that updates the lock files, and then everyone is using the code that is built using the same version of tools. |
Yeah, that's the difference between the software development and the distribution approach. There is actually a long thread on debian-devel about finding ways to make both work at the same time. Historically the problem was solved by introducing shared libraries. Anyway, I'm just trying to cope |
6b5b236 updated all dependencies, so you can feel better at using the pre-compiled sources 😉 The decision is up to you of course, but I'm afraid I won't be able to support multiple build configurations, if a bug report would say "it works fine with the official release or when built from master, but doesn't work via the debian package", I'm afraid I would just have to close those bug reports with "use the official builds". |
Fair enough, I'd prefer using your build system, too, but unfortunately it's not (yet) possible in Debian. Anyway, thanks for your help. If I find something not related to the Debian build itself, I'll open a new ticket. |
@meskes Is using the docker build environment an option for you? That will still compile completely from source. |
@erayd Actually no, the basic idea is that everything is buildable within the distro, so all dependencies and all toold should be packaged. There is some discussion that this has to be changed, but no action yet. |
You could argue that using |
I'll close because it seems there's nothing else we can do here on our side. |
I'm running a selfbuild extension on Linux system with Firefox and Chromium with latest app. Whenever I click on the extension symbol it shows me which URL it searches for, but never returns anything. As long as the popup is active it only shows that turning circle symbol but never any password entry. And also no error message, just nothing.
I've double checked the app version, it is up-to-date.
Any idea how to debug? Or even better, any idea what might be going on?
The text was updated successfully, but these errors were encountered: