Closed Bug 311998 Opened 19 years ago Closed 19 years ago

Update to new browser version breaks all extensions

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: craig+mozilla, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

When you update to a new version of a browser from an older one, extensions
apparently all break, and a new version is needed to restore functionality. 
This is a real pain in the neck when you have more than one or two extensions,
and some of those may not be updated any time soon.  What the heck is this,
1996?  I don't think I've seen such a lame update scheme since binary plugins
back in the day.  And even then, the API didn't change with every point release,
requiring new plugin version every week or two.

Reproducible: Always

Steps to Reproduce:
1.  Install some extensions
2.  Upgrade Firefox
3.  Suffer

Actual Results:  
Only about 3 extensions had new versions available.  The only extension I have
which didn't complain and insist on installing a new version was AdBlock, and
that one didn't update itself, but doesn't actually seem to work any more.  Its
menus are all there in the menu system, but it's not blocking ads, and when I
try and list blockable elements on a page, the list is empty. 

Expected Results:  
the software should have just worked.  That is, extensions which have no good
reason to break should continue to just work without requiring a new version to
be installed.  And extensions which don't claim to need an update shouldn't fail
to work.
This is probably to do with extensions' claimed compatilibity in which case bug
258062 probably applies.

Yeah, this is probably a dupe of that bug, but I think the thread on bug 258062
is misguided -- this is not something that I want as an expert user, it's
something that as a non-expert I'd expect.  I think the ultimate problem here is
that the version-checking is based only on release number, and not based on
whether or not the functionality will actually break.  If an extension depends
on a certain implementation of feature X, then its dependency check should be on
whether or not version Y of feature X supports the extension or not.  If feature
X hasn't changed between browser revisions, then the extension should not be
disabled.  The power users here will figure out how to work around this problem
(like with the Nightly Tester Tools extension which a buddy helpfully pointed me
to).  The non-power users though will wonder why theire helpful toolbar
extension that they're used to has disappeared since that last critical update
they installed, which they were told only patched some security hole, and didn't
change any toolbars.
Well with the new update system, before an update is applied to the browser the
user is warned if some of their extensions would be disabled because of the update.

Also if extension authors keep track of what is going on, they can mark their
extension as compatible with the latest update shortly before it's release so
users would not see their extensions disabled. If they only mark it as
compatible after the fact then users still don't need to update the extension,
firefox would just detect the new compatibility information.

Ultimately the problem is that any change to the browser will affect some
extension or other. What you seem to suggest is to split the browser into a mass
of parts each with its own version and have each extension specify which bits it
uses and what versions it is happy with. That would create hell for extension
authors, hell for firefox developers and wouldn't even get rid of the problem.
Component: Software Update → Extension/Theme Manager
QA Contact: software.update → extension.manager
Extensions always use non frozen interfaces unless they just provide components
- spatial navigation is the only one I can think of that does this and I haven't
checked if it uses non frozen interfaces - since they overlay the app's xul.
Author's can host their extensions and specify less stringent compatibility info
and AMO enforces stricter compatibility info since the complaint would quickly
then become that the extension you are hosting doesn't work with the version it
states it works with. If everything an extension uses was locked down with the
current architecture it would then new functionality / features would become
impossible for all practical purposes and Dave is spot on in his last comment.

Extensions are able to provide the additional functionality by virtue of being
able to interact with a large portion of the app. Partitioning extensions so
they are no longer able to might provide what you are looking for in the way of
compatibility but it would then greatly limit the ability of extensions to
provide the functionality that makes them desirable which I highly doubt anyone
would appreciate. Regretfully it isn't as simple as just allowing extensions to
provide compatibility info that states they are compatible with versions that
haven't been released yet though someone may come up with a solution - more
likely partial solution - in bug 258062. Until then, extension authors need to
verify their extension actually do work with newer releases before their
compatibility info states they work. Hopefully the message that states an
extension will be disabled due to not being compatible, etc. on first launch,
etc. - as Dave points out - will keep the average user from wondering why the
functionality provided by the extension is no longer available.
I don't think this is exactly a dupe of bug 258062 but I think the reasons that
bug was wontfix as well as the reasons stated here are essentially the same. It
is currently a choice between having extension authors verifying their
extensions work and updating compatibility info or having extensions break the
app and until a better solution is created this is wontfix.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → WONTFIX
*** Bug 312147 has been marked as a duplicate of this bug. ***
Howdy programmers.

As a layperson, this is my perspective:  I download Firefox because everybody says it's a better browser.  Maybe my nephew who's in High School helps me to install it.  On the Firefox web page it says "S, M, L or XL—It's Your Choice" and halleluja - I can download extensions that does all kinds of neat stuff.  Block those bleepy ads.  I am happy.

But as it turns out, a new virus or something means that Firefox has to be updated a couple of weeks later.  Now, all users like me hurry up and click on the button-thingy because we don't want the virus.  Do you think we know what the implication is for extensions?  No.  Only after the fact do I realize that half the extensions are now broken, and I can either live with less functionality, or I have to spend an hour trying to downgrade Firefox/update extensions/all kinds of ****.

I am not happy.  It turns out I cannot get "S, M, L or XL—It's Your Choice".  I can get "S, M, L or XL—It's Your Choice (unless you update Firefox)"

This is a big problem with the Firefox browser and needs A LOT of attention.

Maybe this thread should be called "make updates of Firefox lightning fast and side-effect free", or maybe that should be a new bug

Happy coding!
Thanks Mattias -- that's more or less exactly my point.  This may be a big hairy bug, it might even need a big re-architecting or something to get it done.  It might not be something that as a developer one typically thinks of as a "bug", but as a user, this is one gigantically mis-functioning thing.  It absolutely should not work this way, because it will **** people off and make them not want to use Firefox.
Just an additional comment quickie -- the day I originally filed this bug, I installed the Nightly Tester Tools:
http://users.blueprintit.co.uk/~dave/web/firefox/buildid/nightly.html

That was 1.4.1 -- I've now just updated to the 1.5 release, and have worked through every point release in between.  Not one extension has broken when I use the NTT to force them to remain enabled.  Yet if I didn't have NTT installed, I suspect most of them would not be working.
Craig,
Thanks for posting that link!  I went looking for the nightly tools after reading this thread and could not find it.  Let me put it this way:  I am happy.

Thanks,
Mattias
(In reply to comment #7)
> But as it turns out, a new virus or something means that Firefox has to be
> updated a couple of weeks later.  Now, all users like me hurry up and click on
> the button-thingy because we don't want the virus.  Do you think we know what
> the implication is for extensions?  No.  Only after the fact do I realize that
> half the extensions are now broken, and I can either live with less
> functionality, or I have to spend an hour trying to downgrade Firefox/update
> extensions/all kinds of crap.
The compatibility version that is recommended to be used for 1.5 allows security updates to be made to the app without it disabling extensions so the scenario quoted isn't applicable. All an extension author has to do to set their extension as compatible is update this data (it just takes changing a couple of characters in a text file and on AMO it is done via a web form) and then when a user upgrades the app will update this data locally if online which prevents disabling of the extension. This of course doesn't help as much in the reported scenario when using a beta build since many extension authors have not had the time to verify their extension works with the beta yet and it is a very good thing for those users using beta builds that the nightly tester tools are available. I also have over 30 extensions installed and currently only one has not been updated to 1.5 yet by the ext. author.
(In reply to comment #11)
> The compatibility version that is recommended to be used for 1.5 allows
> security updates to be made to the app without it disabling extensions so the
> scenario quoted isn't applicable. All an extension author has to do to set
> their extension as compatible is update this data (it just takes changing a
> couple of characters in a text file and on AMO it is done via a web form) and
> then when a user upgrades the app will update this data locally if online which
> prevents disabling of the extension. This of course doesn't help as much in the
> reported scenario when using a beta build since many extension authors have not
> had the time to verify their extension works with the beta yet and it is a very
> good thing for those users using beta builds that the nightly tester tools are
> available. I also have over 30 extensions installed and currently only one has
> not been updated to 1.5 yet by the ext. author.
> 

When I select Help/Check for Updates, I see an exclamation point and the text "This update will cause some of your extensions and/or themes to stop working until they are updated."  Two of my extensions are on that list, and will be disabled.  I have 10 total, including the "Reporter" and "Talkback".  Then it says "For your protection, it is highly recommended that you update Firefox even if some of your Extensions and Themes become incompatible."  I appreciate that, but like was said by the original poster, apparently these Extensions, if they were not disabled, would most likely work just fine so why are we disabling them in the first place?

Having Extension/Theme writers be forced to keep a close eye on development of the main product is not a great solution.  How about Extensions/Themes were only turned off forcibly if a Major new version was released?  Or, how about if a "safe mode" could be available if Firefox crashes as a result of a broken extension/theme?  Anything except turning them off.

I keep coming back to comparing with other browsers - this simply makes Firefox high maintenance for the user.  Think about it - it would take an awful lot for me (a techy person) to switch back to IE - but it won't for a "regular" user.  They will run into this Extension thing once and they're gone.

PS - I didn't realize until now that this mess also applies to Themes
(In reply to comment #12)
> Having Extension/Theme writers be forced to keep a close eye on development of
> the main product is not a great solution.  How about Extensions/Themes were
> only turned off forcibly if a Major new version was released?  Or, how about if
> a "safe mode" could be available if Firefox crashes as a result of a broken
> extension/theme?  Anything except turning them off.

This is already in place in Firefox 1.5. Extension and theme authors can say their extensions are compatible with 1.5.0.* which will be the versions for those updates that do not affect extensions.

Having hung out on the IRC channel for some time now I guess I'd say that 40% of all the problems were caused by bad extensions (around 50% are from the profile locking issue that is mostly solved in 1.5). As far as I'm concerned automatically disabling extensions after an update is a good thing to do. It would also be interesting to see the number of users that actually use extensions, I wouldnt be surprised if its as low as 5%.

Also, other browsers don't allow extensions to access / modify anywhere near as much as Firefox, etc. allows and as with most things of this nature there is a trade-off because of it. It may be possible to accomplish some of the desired result but it isn't going to be by just allowing extensions to be considered compatible by the Extension Manager.

BTW: and for themes it is just as important - try opening the options / preferences window with a 1.0 only theme
I'm voting for this behaviour being considered a bug, too.

I'm a plain old firefox *user*, not a developer -- although I learned a little javascript to write a couple of Greasemonkey user scripts a few months back. ;)

I upgraded from FF 1.0 to 1.5 when that was released (skipping the betas), and immediately ran into this awfulness.

Among my can't-live-without extensions that were broken by this upgrade: MozEX: http://mozex.mozdev.org/ .  I'm still using this, even though the last release was in 2003.  The developer obviously has no intention of releasing a new version to pass the firefox check, every time FF releases.

In response to Comment #15
Exactly!  But like someone said: it's a big, hairy bug.  With risk of being unfair, "auto disable" all extensions after update is a simple alternative to keeping enough consistency in code and interface so that extensions and themes do not break.  I can see how this got marked as "resolved wontfix" for that reason, and in reality will never be fixed.  But just because it's a big, hairy bug does not make it go away.  Where else than the bug tracking system should an issue like this go?  That's a rhetorical question, by the way.

So... time to be constructive:  How about this bug could be geared towards getting a way for a normal user to re-enable extensions/themes at their own peril (without having to install the obscure nightly tester tools)?  There needs to be a way to automatically disable extension/themes after use of "version override" if anything _does_ cause a big problem.
(In reply to comment #16)
> There needs to be a way to automatically disable extension/themes after use of
> "version override" if anything _does_ cause a big problem.

That would be bug 258062
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.