256509 - Installing / uninstalling of classic extensions without restarting

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[Jaap A. Haitsma]

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:

Comment 1

[Logan Ingalls]

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

Comment 2

[Martijn Wargers (dead)]

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

Comment 3

[Crystle Numan]

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!

Comment 4

[Greger Cronquist]

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.

Comment 5

[stupendo44]

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.

Comment 6

[Sohail Mirza]

(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).

Comment 7

[Wladimir Palant]

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.

Comment 8

[Eyal Rozenberg]

(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.

Comment 9

[Brendan Eich [:brendan]]

Focus on adding without restart -- do that first.

/be

Comment 10

[Mike Shaver (:shaver emeritus)]

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

Comment 11

[anatolyg]

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?






 
 

Comment 12

[Nickolay_Ponomarev]

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.

Comment 13

[anatolyg]

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

Comment 14

[Dave Townsend [:mossop]]

(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.

Comment 15

[anatolyg]

"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

 

Comment 17

[Alfred Kayser]

And themes too!

Comment 18

[Dave Townsend [:mossop]]

(In reply to comment #17)
> And themes too!

That is bug 226791

Comment 21

[aicitman]

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.

Comment 22

[Dave Townsend [:mossop]]

(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

Comment 23

[Paul [pwd]]

(In reply to comment #22)

Shouldn't this be WONTFIX then? With a link to the Jetpack page of the Wiki?

Comment 24

[Alfred Kayser]

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?

Comment 25

[Jorge Villalobos [:jorgev] (he/him)]

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.

Comment 26

[Biju]

(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.

Comment 27

[Alfred Kayser]

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

Comment 28

[Dave Townsend [:mossop]]

(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.

Comment 30

[Eugen Paraschiv]

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.