Closed Bug 1309288 Opened 8 years ago Closed 4 years ago

Install addons permanently from about:debugging

Categories

(DevTools :: about:debugging, defect, P2)

Product:
DevTools
Component:
about:debugging
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: ochameau, Assigned: ochameau)

References

Details

(Keywords: dev-doc-needed)

Attachments

(2 files)

Bug 1309288 - Install addon from sources permanently from about:debugging.
(deleted), text/x-review-board-request
Details
install-permanent-addon-two-buttons.png
(deleted), image/png
Details
Followup from bug 1185460. bug 1185460 focused on providing the AddonManager internal necessary to install addons permanently. Now we just need to tweak about:debugging UI to use that new platform feature. We do have an existing entry: "Load temporary add-on". Which is going to install any addon, even unsigned, even without the signature magic pref. But this addon is going to be transcient and disappear on next Firefox startup. This is actually painful when you are testing behavior of your addon on startup or reboot! Or if you happen to easily break firefox and need to restart firefox while developing your addon. Now, the new installation method will allow permanent install of signed addon, but unsigned one, the typical usage when you are loading sources directly, is going to fail unless you toggle the signature pref. It is not clear what UI we should end up with. Should we replace the "load temporary add-on" with just a "load add-on" and have different behavior based on the pref? Should we encourage setting the pref to false? Should we display "load temporary add-no" or "load add-on" based on the pref value? What about the behavior on release where we can't toggle the pref?
Julian, Andy, Robert, Any feedback?
Flags: needinfo?(rhelmer)
Flags: needinfo?(jdescottes)
Flags: needinfo?(amckay)
(In reply to Alexandre Poirot [:ochameau] from comment #0) > Followup from bug 1185460. bug 1185460 focused on providing the AddonManager > internal necessary to install addons permanently. Now we just need to tweak > about:debugging UI to use that new platform feature. > > We do have an existing entry: "Load temporary add-on". Which is going to > install any addon, even unsigned, even without the signature magic pref. But > this addon is going to be transcient and disappear on next Firefox startup. > > This is actually painful when you are testing behavior of your addon on > startup or reboot! Or if you happen to easily break firefox and need to > restart firefox while developing your addon. > > Now, the new installation method will allow permanent install of signed > addon, > but unsigned one, the typical usage when you are loading sources directly, > is going to fail unless you toggle the signature pref. > > It is not clear what UI we should end up with. > Should we replace the "load temporary add-on" with just a "load add-on" and > have different behavior based on the pref? > Should we encourage setting the pref to false? > Should we display "load temporary add-no" or "load add-on" based on the pref > value? > What about the behavior on release where we can't toggle the pref? I suggest that we only show the button to load from a source dir if the signature pref is disabled. If you want to make it more discoverable, maybe have a disabled button with a message saying that this feature can only be used if signature checking is disabled - this seems a bit cruel to release users since it's not possible for them to do though, so just hiding the button might be better. As an aside, Chrome calls this loading an "unpacked extension", you may want to consider using the same terms in our UI.
Flags: needinfo?(rhelmer)
I'm not in favour of UI that magically changes depending upon prefs, its confusing for users to understand and hard to document. I would suggest: * hiding the button on release * having the button present but not clickable with a link to MDN on how to turn off signing The term "Unpacked" also suggests that we are talking about add-ons that are not bundled into a .zip or .xpi. Will this button allow the loading of an .xpi or directory like "load temporary addon". And if so, presumably we'll have similar problems about the folder or file selection?
Flags: needinfo?(amckay)
(In reply to Andy McKay [:andym] from comment #3) > I'm not in favour of UI that magically changes depending upon prefs, its > confusing for users to understand and hard to document. I would suggest: > * hiding the button on release > * having the button present but not clickable with a link to MDN on how to > turn off signing sgtm > The term "Unpacked" also suggests that we are talking about add-ons that are > not bundled into a .zip or .xpi. Will this button allow the loading of an > .xpi or directory like "load temporary addon". And if so, presumably we'll > have similar problems about the folder or file selection? No, this feature only allows directories.
The main usage is obviously picking an unpacked addon, its sources, so its folder. But we *can* also load xpi/zip directly. I have no idea how useful it is to also support that. Have you heard or seen anyone using about:debugging "load temporary add-on" with a packaged addon?
(In reply to Alexandre Poirot [:ochameau] from comment #5) > The main usage is obviously picking an unpacked addon, its sources, so its > folder. > But we *can* also load xpi/zip directly. I have no idea how useful it is to > also support that. > Have you heard or seen anyone using about:debugging "load temporary add-on" > with a packaged addon? Hm, I didn't realize you could point a proxy file to a XPI - that doesn't seem particularly useful. People do use "load temporary add-on" with XPI files. I think some of Firefox tests do this, web-ext/jpm might as well.
(In reply to Alexandre Poirot [:ochameau] from comment #5) > The main usage is obviously picking an unpacked addon, its sources, so its > folder. > But we *can* also load xpi/zip directly. I have no idea how useful it is to > also support that. > Have you heard or seen anyone using about:debugging "load temporary add-on" > with a packaged addon? I would strongly support loading directories too, I think that's the best way to go. At least one example of someone being surprised by this is bug 1283656. I would say that if one allows .xpi and directories and the other only directories we might need better UX pixie dust to explain this.
Sounds like a useful feature! I'm in favor of having a separate button here, but I don't think we should ever hide it. It makes the feature harder to discover. Even if on release this pref can not be toggled, the tooltip could hint at downloading DevEdition or Nightly to use the feature. Someone visiting about:debugging#addons is already committed to invest time to debug addons, and I think would be happy to know that another version of Firefox could make the debugging easier.
Flags: needinfo?(jdescottes)
Thanks for the feedback all, I'll try to implement that next week.
Assignee: nobody → poirot.alex
Consider this patch as a proposal we could iterate on. It keeps the existing "Load temporary add-on" button 100% as-is. And adds a "Load unpackaged add-on permanently" next to it. Disabled on release or if the signature pref is true. Different tooltips appear depending on that: - "This feature only works on non-release build like Developer Edition or Nightly" - "'xpinstall.signatures.required' preference needs to be toggled to false" This new button opens a directory-only file picker. My gut feeling is that having two buttons feel complex for obscure reasons. I wish we could end up with just one. But may be that complexity would be soften by a unique "Install add-on" button, which prompts a menu with two items: - Install temporarely a packaged addon - Install unpackaged add-on from a directory permanently We could add a third item refering to an helpful MDN page about addon signatures, focused on about:debugging workflows?
Comment on attachment 8803931 [details] Bug 1309288 - Install addon from sources permanently from about:debugging. https://reviewboard.mozilla.org/r/88124/#review91244 The feature works well, thanks! As you said we should first try to decide on the UX. My first question is about the type of filepicker being used. The one for temporary addons is a file picker, the one for permanent install is a directory picker. Couldn't we just use a file picker for both ? With the same logic of picking the parent folder if the selected file is not an *.xpi file? Then we have several options for the actual UI. We should keep in mind that the "permanent" option will be disabled by default for most users, they need to have an easy way of knowing why. Having two separate buttons is probably the simplest approach, we should however change the layout to group them together and stick them on the right side of the UI. I also like your proposal of using a menubutton (with a 3rd entry for documentation). Would you have time to prototype it? One last option I was thinking about was to have single button "Load addon". Clicking on it opens a filepicker. When the filepicker is submitted we display another dialog asking whether the addon should be "loaded for this session only" or "installed permamently". That might be a bit too cumbersome when using the feature repeatedly. Small detail, it would be nice to observe preference changes and to update the button if `xpinstall.signatures.required` changes.
Attachment #8803931 - Flags: review?(jdescottes)
As mentioned in my previous comment, this is just a small layout modification to make the "2 buttons" approach a bit more user friendly.
(In reply to Julian Descottes [:jdescottes] from comment #12) > Comment on attachment 8803931 [details] > > My first question is about the type of filepicker being used. The one for > temporary addons is a file picker, the one for permanent install is a > directory picker. Couldn't we just use a file picker for both ? With the > same logic of picking the parent folder if the selected file is not an *.xpi > file? Andy reported that various addons developers have been confused with this somewhat magic behavior. See comment 3 and 7. But yes I agree, it is also disturbing to have two somewhat similar buttons with different behavior. > Then we have several options for the actual UI. We should keep in mind that > the "permanent" option will be disabled by default for most users, they need > to have an easy way of knowing why. Yep! > Having two separate buttons is probably the simplest approach, we should > however change the layout to group them together and stick them on the right > side of the UI. Simplest implementation, not sure simplest to understand/use? > I also like your proposal of using a menubutton (with a 3rd entry for > documentation). Would you have time to prototype it? Yes, but mozreview wouldn't allow me to attach two branches to the bug. So it will replace the first one :x > One last option I was thinking about was to have single button "Load addon". > Clicking on it opens a filepicker. When the filepicker is submitted we > display another dialog asking whether the addon should be "loaded for this > session only" or "installed permamently". That might be a bit too cumbersome > when using the feature repeatedly. I think I prefer the menu option over the flying dialog. It looks like a more common and accessible UI.
Priority: -- → P2
I think that if add-ons are going to be installed permanently it should show the WebExtensions permissions as per: https://wiki.mozilla.org/WebExtensions/Permissions and https://bugzilla.mozilla.org/show_bug.cgi?id=1308292. I was chatting to aswan about this and there was concern that there might a different install path for this flow that doesn't go through add-ons manager? First question is probably to Markus though, could we confirm that if someone installed a WebExtension permanently, it should show the permissions dialog? We decided that if its temporary it shouldn't because that would just be insanely annoying for development.
Flags: needinfo?(mjaritz)
Flags: needinfo?(aswan)
(In reply to Andy McKay [:andym] from comment #15) > I was chatting to aswan about this and there was concern that there might a > different install path for this flow that doesn't go through add-ons > manager? My concern isn't that the new path doesn't go through the add-ons manager, but that it is so different from the existing paths. We have a class called AddonInstall that manages the sequence of events that need to happen when an addon is installed, which includes things like applying an update if the addon is already installed, giving upgrade listeners an opportunity to delay the upgrade, etc. My plan was to handle permissions prompts for webextensions there too. Bug 1185460 created a new code path for installs that doesn't use AddonInstall (it actually re-used the temporary install path, but that's a strange choice since the requirements for temporary add-ons are so different). That means that add-ons installed using the feature in this bug won't properly handle things like upgrade listeners, and we'll have to implement the permissions flow separately for the install code path it uses. I think we'll be better off in the long run if we can make `installAddonFromSources()` look much more like existing addon installations.
Flags: needinfo?(aswan)
(In reply to Andy McKay [:andym] from comment #15) > First question is probably to Markus though, could we confirm that if > someone installed a WebExtension permanently, it should show the permissions > dialog? We decided that if its temporary it shouldn't because that would > just be insanely annoying for development. I see the reason for not showing permissions for temporary installs as: It is a feature targeted at developers (which normal users shouldn't use - if the do not understand the implications). The real power of those developer options of installing extensions comes from being able to install unsigned extensions. (potentially malicious ones) I assume this is even more true for installing extensions permanently from about:debugging. If so, we should find a way to indicate to users that they are in a less safe developer mode and give them an option to rectify that if they did not intend to use developer features. I do not think that showing permissions once will help much with that. It might even ensure users that this is a regular extension-install. Only being able to load unpacked extensions (folder) instead of regular *.xpi will also support the fact that this is not a regular install. And I think that Chrome notifies users on each restart if an unpacked extension is installed, which also helps to not have users unintentionally having a unsigned extension installed. Why are we providing temporary and permanent install in about:debugging? I understand that in release only temporary is available. Do we need temporary in pre-release, if permanent is available? If we need both, having a disabled button that indicates (in its tooltip) that signing must be turned off to use it, can be a simple way.
Flags: needinfo?(mjaritz)
Depends on: 1339552
No longer depends on: 1339552
Product: Firefox → DevTools

I am also affected by this bug: i have developed my own addon and i am now facing a pain to install it in all my copies of firefox. I don't want to disable signature checking completely, i just need a quick and easy way to install this single addon from surce, just like "Load temporary Add-On", but permanent. What i am doing by now is just reinstalling it every time i close/reopen Firefox… quite annoying.

Not sure if that's relevant, but different browsers also allow permanent installation of unpacked/unsigned addons in their "standard" release with just a couple of clicks.

Alexandre Poirot's solution seems to be perfect for me. Any chance i can enable it on my "standard" firefox 78 without having to recompile it from source?

Thanks!

Alexandre Poirot's solution seems to be perfect for me. Any chance i can enable it on my "standard" firefox 78 without having to recompile it from source?

Sadly no, this patch was for an older version of the about:debugging UI, which is no longer in Firefox today.

Since this bug was opened I think webext has become the goto place for addon development so I don't know if we should try to revive this feature, or if there is a better workflow already in webext (https://extensionworkshop.com/documentation/develop/getting-started-with-web-ext/ in case you are not using it yet).

Philipp: is there a good workflow for webextension developers who want to test scenarios that involve closing / re-opening firefox? Or should we try to revive this "install addon permanently" feature?

Flags: needinfo?(philipp)

The lack of this feature is one of the main reasons I don't use Firefox regularly, and why the extension I help maintain doesn't get nearly as much testing in Firefox, because it's a huge PITA comparatively.

Luca: Can you take a look at comment 20 and let me know what you think?

Flags: needinfo?(lgreco)

(In reply to Julian Descottes [:jdescottes] from comment #20)

Alexandre Poirot's solution seems to be perfect for me. Any chance i can enable it on my "standard" firefox 78 without having to recompile it from source?

Sadly no, this patch was for an older version of the about:debugging UI, which is no longer in Firefox today.

yeah, the approach in the attached patch is not going to work anymore, I just checked and the AddonManager.installAddonFromSources (originally introduced in Bug 1185460) has been also removed some times ago.

Since this bug was opened I think webext has become the goto place for addon development so I don't know if we should try to revive this feature, or if there is a better workflow already in webext (https://extensionworkshop.com/documentation/develop/getting-started-with-web-ext/ in case you are not using it yet).

Philipp: is there a good workflow for webextension developers who want to test scenarios that involve closing / re-opening firefox? Or should we try to revive this "install addon permanently" feature?

We do have some docs related to the strategies that can be used to test scenarios that requires restarting Firefox as part of the following doc page:

As the section linked above describe, to test restart behaviors we currently suggest to install the extension permanently using a Nightly/DevEdition or unbranded build for Beta and Release and disabling the xpi signature checks, possibly in a separate development profile (to avoid exposing a default profile that the user may use for regular browsing to more threats by allowing unsigned extensions).

A Firefox ESR version is also an option, the xpi signature checks can also be disabled on ESR (and this is likely the best option for users that wants to install an unsigned extension permanently if they prefer to not use Nightly or DevEdition versions).

In the past few years we discussed quite often about which issues may be introduced by allowing to permanently installing an unsigned extension on release, and there were always concerns about the way it may be abused my malicious actors.
I have some doubts that the discussion would have a different outcome now (as far as I know there wasn't any change that may brings something to the table which would avoid those concerns), but I'm leaving the needinfo assigned to Philipp in case he has a different opinion.

Flags: needinfo?(lgreco)

there were always concerns about the way it may be abused my malicious actors.

I understand why this is the justification for restricting traditional addon installations. Signed addons from AMO eliminate the possibility of naive users being duped into installing malware addons from any random shady site on the web with a couple clicks, which can come across as pretty legit.

install the extension permanently

Comparing a traditional addon install, to the ability to load an unpacked, local extension persistently, is a false equivalence. Nobody's getting duped into jumping through all the hoops, and not noticing all the bright flashing warnings along the way.

We develop extensions with stable compatibility in mind, so telling developers to use some ancient or alpha versions for testing is also silly. For the most part, the best beta testers are the developers themselves. Thorough testing doesn't take place inside a vacuum, and can't be accomplished in temporary sessions.

Developers need the ability to debug persistently, in the same environment as the end user. We can do so in Chromium. Even Google Chrome allows for it with the stupid warning on launch. Firefox could do something similarly annoying, but ideally provide a config to disable it.

I'm not convinced we should pursue this path of allowing permanent installation of unsigned add-ons via about debugging. There are multiple alternative paths that would allow developers to test behavior of the add-on which have been previously mentioned. They may not lead to the highest level of convenience w.r.t loading unpacked extensions into Firefox for development, but there are some trade-offs we need to make.

My recommendation would be to make use of Nightly along with web-ext. While you are immediately bugfixing you can use web-ext run or load temporary add-on to see if it is working, once you believe you've reached a stable point you can use web-ext sign to obtain a copy that will be installable persistently.

I'm sorry I can't offer you a better alternative at the moment, but I appreciate you getting in touch and letting us know about your use case.

Status: NEW → RESOLVED
Closed: 4 years ago
Flags: needinfo?(philipp)
Resolution: --- → WONTFIX

My use case is probably uncommon but quite simple: i develop an extension myself and i have no plans to distribute it, since nobody else would be interested. I am the only tester and developer. This means i can't use a dedicated Firefox instance to debug: testing is just everyday's usage… or go to the complication of packaging/signing it every time i made a small update: packaging would take longer than coding.

Loading it through about:debug works just fine, it even allows me to reload it in a click when i modify something. The only problem: it is not permanent.

My current workaround: i never close Firefox. Unfortunately Firefox slows down over time and after a few days i am forced to close/restart it anyway, or because of updates started to force a reload recently.

Sadly, other browsers just have this feature.

My 2c

I understand and acknowledge that this can be inconvenient in some cases. I'd recommend looking into web-ext. While I wouldn't recommend signing every change you'd make in the day, signing for self-hosted via web-ext when you are comfortable with the changes you've made is just one command line call away.

(In reply to Philipp Kewisch [:Fallen] [:📆][:🧩] from comment #27)

I understand and acknowledge that this can be inconvenient in some cases. I'd recommend looking into web-ext. While I wouldn't recommend signing every change you'd make in the day, signing for self-hosted via web-ext when you are comfortable with the changes you've made is just one command line call away.

Obviously, you can slap a WONTFIX on whatever you want - that's your prerogative. I guarantee you it's the wrong call on this one, and that the decision is shortsighted.

I understand and acknowledge that this can be inconvenient in some cases

It's not inconvenient in some cases, it's inconvenient in all cases, all the time, for all extension developers. Myself, and a handful of other developers maintain Stylus. I mention that not because I think it's something special, but to point out that none of us develop in Firefox, because you've made it a huge PITA to do so.

Firefox specific bugs slip by all the time and make it into stable, because while everyone tests multiple versions of Chromium on a daily basis, Firefox stable might get a quick run through before releases. The lack of this feature would make it impossible to use Firefox as a regular browser, which I would certainly be inclined to try otherwise. At the very least, Firefox would get considerably more attention.

We develop as we use the extension. I have five different versions of Chromium, each of which I can open and instantly test the latest edits, because they all load unpacked local extensions persistently. In many cases, you need to test in multiple versions. Ideally, you always try to.

Keep the baby-gates up for typical extension installs, but when it comes to the inability to load unpacked extensions persistently, you're relegating Firefox to an afterthought in terms of extension development. It's the browser you begrudgingly jump through hoops to test, typically long after Firefox specific bugs are introduced.

At the end of the day, it seems like your mind is made up, so it's unlikely anything I say here is gonna change that. Only reason I bother urging you to reconsider, is the fact that you seem to drastically underestimate the inconvenience, to the detriment of your own webExtension ecosystem.

(In reply to Philipp Kewisch [:Fallen] [:📆][:🧩] from comment #27)

I understand and acknowledge that this can be inconvenient in some cases. I'd recommend looking into web-ext. While I wouldn't recommend signing every change you'd make in the day, signing for self-hosted via web-ext when you are comfortable with the changes you've made is just one command line call away.

That's not one command line call away: that's yet another software to install, including npm, and all the docs to read. Also, it looks like web-ext wants to start a dedicated Firefox instance, so it will destroy my workflow of using the same session i'm using for everyday browsing anyway.

This is not only about laziness, this is about giving to the user the freedom to use the software the way he needs. The choice of not allowing "unsigned" extensions is surprising, considering other browsers that i believed to be less freedom-friendly are just allowing it.

Just chiming in to give a big +1 to sleepwalkingnarcolepticinsomniac and Gabriele's comments on this thread.

I develop several extensions and I basically always want to be running the development version in my browser for daily testing and tinkering. It's very frustrating to have to manually load several "in development" extensions afresh every time I restart Firefox.

After several months of trying Firefox instead of Chrome as my primary browser, this pain point is the main reason I'm seriously considering going back to Chrome.

I hope this extra comment is helpful, and you'll get a chance to reconsider this feature sometime. Thanks!

For those still looking for a way to automatically load an unpacked Firefox extension from a local directory, please take a look at this solution: https://github.com/tsaost/autoload-temporary-addon

From README.md:

The procedure involves a few steps, but it needs to be done only once.

First you need to enable AutoConfig aka userchrome.js by copying the file config-prefs.js to [Your Firefox install directory]/defaults/pref

Note: For best security, on Windows it is best to leave your Firefox install in "c:\Program Files" so that your config-prefs.js and userChrome.js can only be modified when you are in root/admin mode.

Then you need to edit the file userChrome.js and modify the function installUnpackedExtensions() to reflect the locations of your own addons.

The modified userChrome.js then must be copied to your Firefox installation directory. For example, on Windows this is usually "c:\Program Files (x86)\Mozilla Firefox" for the 32-bit version of Firefox. You can rename the file, but remember to modify the corresponding line pref("general.config.filename", "userChrome.js") in defaults/pref/config-prefs.js

Now your addons from your local directories will be loaded automatically whenever Firefox starts. After editing your code, remember to reload it from about:debuggin. You can also get there via the menu by selecting "More Tools", then "Remote Debugging", and click on "This Firefox" on the left side (but the quickest way is to bookmark it and then add a bookmark keyword such as "dbg" for quick access.)

Please note that this is an automated installation of the extension every time Firefox starts, so it is not quite the same as a "permanent install". That is, this procedure has exactly the same effect as clicking on "Load Temporary Addon..." from the about:debugging page, just that the process is now automated via userChrome.js. This means that if you have code that does something after the installation of the extension such as browser.runtime.onInstalled.addListener(details => { if (details.reason == "install") { ...do something after install... }); then this code will be called every time Firefox is launched.

Because the extension is re-installed every time, you must make sure you have browser_specific_settings such as "browser_specific_settings": {"gecko": { "id": "you.extension.your.name@gmail.com" }} in your manifest.jason or changes to your options and local storage will be lost when you restart Firefox.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: