User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040809 Firefox/0.9.3 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040809 Firefox/0.9.3 It would be really cool if you could install / uninstall extensions without restarting your browser Reproducible: Always Steps to Reproduce:

I really thought there would be a dupe for this, but there isn't as far as I could see. Related bugs: Bug 226791 - fix dynamic theme switching feature Bug 218947 - button to restart browser after an extension is installed

*** Bug 275022 has been marked as a duplicate of this bug. ***

I don't fully understand all that is in involved with needing FireFox to restart. Also, I don't know how extensions work with multiple users, ie. Linux box or WinXP. What I found was that a Linux user on an thin client with App server could not "restart" firefox. He installed an extension, closed FireFox (his instances of them), but the extension still said "This will be available after you restart Firefox". I'm wondering if someone can explain this behaviour. Then I can make a more informed bug report/enhancement request, if needed. Also, will all the users on this thin client network now have the user agent switcher extension, or only the one guy who installed it? Thanks!

I agree with the reporter; having to restart the firefox/mozilla in order to add or remove functionality or appearance is a little bit too much like Microsoft Windows to me. It wood be great if it weren't necessary.

AFAIK, the main reason a restart is currently required is because of the XUL overlays. The overlays are loaded dynamically as firefox starts. It does seem to me, though, that it should be possible to restart only selected parts, rather than the whole app.

(In reply to comment #5) > AFAIK, the main reason a restart is currently required is because of the XUL > overlays. The overlays are loaded dynamically as firefox starts. If this is true, then I believe any solution to this bug will depend on bug 282103. Bug 282103 will implement truely dynamic overlays, which should allow dynamic extension installs/uninstalls as well (if my understanding is correct).

The issue with overlays is not just loading them dynamically. Most overlays attach to the "load" event of the window for initialization, loading them after the window loaded will break them. And unloading overlays from a window would mean unloading all of the JavaScript code they attached to the window - I don't think this is possible. But while you could simply say that extension installation/uninstallation doesn't affect already open windows, the issues with XPCOM components are even more complicated. If the XPCOM component depends on being called at application startup (which they often are) - I don't know how these are supposed to be activated at runtime. And for uninstalling you wouldn't need to unregister the component everywhere - I don't think the module's unregisterSelf function can be relied on.

(In reply to comment #7) > Most overlays attach to the "load" event of the window for initialization, > loading them after the window loaded will break them. Ok, so what? Extension authors will write new versions which support this and don't break. As for compatibility with older extensions... well, we'll think of something. Maybe reloading a window but not the whole app. > And unloading overlays from a window would > mean unloading all of the JavaScript code they attached to the window - I > don't think this is possible. So extension authors will need to write cleanup routines triggered by unload events. About XPCOM components - I'm not knowledgable enough to comment. Hopefully this could also be dealt with by expecting extension authors' cooperation.

Focus on adding without restart -- do that first. /be

As has been discussed in various fora including the Firefox 3 PRD, it's entirely acceptable and likely that we will require explicit author support to make an add-on installable without a restart. Uninstallation is much less interesting, and much harder, and we should separate the bugs. Advocacy comments are not useful in this discussion, as it's already something that we know we want to do -- people need not tell us again that it's desirable. Mike

Restart page not required in Firefox 2.0.0.14 and now required in Mozilla Firefox 3 Beta 5 1) open html.test page in Firefox 2.0.0.14 that uses my test plugin 2) copy test.dll and test.xpt to C:\Program Files\Mozilla Firefox\plugins folder (executable installer will do that) 3) In this way restart or reload page is not required: page can use plugin In Mozilla Firefox 3 Beta 5 this is not working. Restart of FireFox is required after i copy test.dll and test.xpt to C:\Program Files\Mozilla Firefox\plugins folder Any ideas what can be done to avoid restart of FireFox?

re comment 11: your comment is totally unrelated to this bug. Please either file a separate bug or post your question to the plugins newsgroup.

Can you explain why? I am looking here: http://developer.mozilla.org/en/docs/Shipping_a_plugin_as_an_extension "As of Firefox 3 (and any Gecko 1.9 based application) the use of install.js scripts is no longer possible and plugins must either be shipped as an executable installer or as an extension as described here." And here you are talking about making an add-on installable without a restart. Thanks

(In reply to comment #13) > Can you explain why? Your comment talked about copying files directly to the plugins folder, this is not what is meant by shipping a plugin as an extension. If those file copies used to just work and don't then it is a separate issue. Any further comments in this bug that aren't helping fix installing extensions without restart aren't useful.

"Plugins must either be shipped as an executable installer or as an extension as described here." I need the way to install plugin that not requires restart of FirFox - executable installer that copying files directly to the plugins folder is working fine in Firefox 2.0.0.14 and the question is if it is bug that it is not working in Mozilla Firefox 3 Beta 5? Please specify link to "plugins newsgroup" - i also would like to check option to ship plugin as extension if you already implemented options "will require explicit author support to make an add-on installable without a restart" what is a status of this issue? please give me any additional info Thanks

And themes too!

(In reply to comment #17) > And themes too! That is bug 226791

This bug is taking years. Why doesn't someone just do it? I'll gladly try to do it, if someone will explain to me the requirement to restart, where the code is, and where I could learn the language from. Because this bug is one of the biggest bugs ever in Firefox's history.

(In reply to comment #21) > This bug is taking years. Why doesn't someone just do it? Because the sheer amount of work involved in making it work for the general case has never seemed worth it. Instead we have been focusing on things like the jetpack project where we can achieve this by restricting how much freedom extensions have in the platform

(In reply to comment #22) Shouldn't this be WONTFIX then? With a link to the Jetpack page of the Wiki?

Or we can say it is 'fixed' by Bug 555349 - Finalize the restartless add-on format, which adds the possibility for extensions to make them installable without restart?

I don't think this bug should be closed because of the possibilities that Jetpack or the restartless add-on feature offer. This bug is about "classic" extensions, the wide majority of which aren't Jetpacks (yet?) and can't be restartless because they rely on overlays. I think it would make sense to WONTFIX this once "classic" extensions become a minority, if that ever happens. There's still a real need for this, but it's just too hard to solve.

(In reply to comment #22) > Because the sheer amount of work involved in making it work Can we get a "extension disabled" and "extension uninstalled" event with extension id and version while user disable or uninstall extension. This will allow extension developer to write code for immediately disabling extensions, when user disable/uninstall it.

That is precisely where the 'bootstrap' feature is for, See bug 555349 and https://wiki.mozilla.org/Extension_Manager:Bootstrapped_Extensions.

(In reply to comment #25) > I don't think this bug should be closed because of the possibilities that > Jetpack or the restartless add-on feature offer. This bug is about "classic" > extensions, the wide majority of which aren't Jetpacks (yet?) and can't be > restartless because they rely on overlays. I totally agree that these are separate issues. The new restartless add-ons are great but cannot be used for all types of extensions right now. > I think it would make sense to WONTFIX this once "classic" extensions become a > minority, if that ever happens. There's still a real need for this, but it's > just too hard to solve. However I think we have to be realistic. Before we even had the restartless add-ons we did not have enough of a reason to fix this bug. Now that we have them I don't imagine we're even going to look at this again. I don't think there is much point in keeping a bug open that I don't foresee ever being fixed.

Restartless add-ons should be the norm, not the exception. Unfortunately this is not the case (many versions later) and it's not likely to become the case if the underlying platform doesn't nudge the entire environment in the right direction. I understand the pragmatic viewpoint, but the end user doesn't care that the feature is supported or not, or that it even exists. So keeping the bug open for something that still is a real problem is the only thing to do. As for the solution, perhaps something can be done to nudge the issue forward, such as only including restartless add-ons in the official Firefox add-on marketplace - so that there is an actual incentive to make the plugin restartless - to get into the official marketplace.