Closed Bug 258062 Opened 20 years ago Closed 20 years ago

Extension/Theme Manager should allow user-override to install incompatible (wrong version) extensions/themes

Categories

(Toolkit :: Add-ons Manager, enhancement)

Product:
Toolkit
Component:
Add-ons Manager
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: fishbert, Assigned: bugs)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040902 Firefox/1.0 PR (NOT FINAL)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040902 Firefox/1.0 PR (NOT FINAL)

When trying to install an extension or theme with (for example) maxVersion set
to 0.9 to an installation of Firefox with version 0.10, the Extension/Theme
Manager returns an error, "xxxxx could not be installed because it is not
compatible with this version of Firefox."

The user should be presented with an option to over-ride this error and install
the extension/theme anyway under a "use at your own risk" precept.

In summary, the user should be allowed to say, "Hey, Firefox, I'm a big boy/girl
and believe I can make this decision for myself.  Thanks for the warning, I have
taken it under consideration, but I'd like to install this anyway."


Reproducible: Always
Steps to Reproduce:
1. Attempt to install (for example) the theme "Lila 1.5" on Firefox 1.0PR nightly.

Actual Results:  
"Incompatible Extension" error dialog box is presented reading: "Lila 1.5 could
not be installed because it is not compatible with this version of Firefox.
(Lila 1.5 will only work with Firefox versions from 0.8 to 0.9)"


Expected Results:  
"Incompatible Extension" error dialog box is presented reading: "Lila 1.5 could
not be installed because it is not known to be compatible with this version of
Firefox. (Lila 1.5 is only known to work with Firefox versions from 0.8 to 0.9.)

Attempt to install anyway? (This may cause Firefox to become unusable, and is
not a recommended action!  Use at your own risk!)"  <-- the parenthetical
preferably in bold face.

With yes/no buttons at the bottom (default "no").
Depends on: 247322
Providing a prompt for the average user to click yes to without thinking kind of
defeats the purpose of the compatibilty check. In my opinion, if "power users"
really want to install an older theme/extension, they can modify the
theme/extension to have a higher maxVersion. This would just cause a lot of
problems IMO.

I'd WONTFIX this if it was up to me.
If someone has a great many extensions they wish to install, it's a real pain in
the ass to manually patch them one-by-one.  Power users are users too... users
who generally don't like wasting a lot of time with tedious work-arounds.

Yes, guarding against user stupidity is important, but not at the expense of
taking overall control away from the user.  Giving a yes/no option defaulting to
"no" and with a very prominant "do you really know what you're doing here?"
message does not sound unreasonable in my opinion.  In essence, this proposed
equivalent of a "-force" command-line parameter would be an extremely useful thing.
Yes, I too think that it should be made available (say, as an option in
about:config).

That would save a lot of time for people like Samir Boulema and friends at
extensionmirror.nl, who have to repackage it, as most of extensions actually
work in newer releases.

Confirming as a valid enhancement request, let Ben decide if it should be
wontfix'ed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Extension/Theme Manager should allow user-override to install "incompatable" extensions/themes → Extension/Theme Manager should allow user-override to install "incompatible" extensions/themes
*** Bug 262672 has been marked as a duplicate of this bug. ***
Summary: Extension/Theme Manager should allow user-override to install "incompatible" extensions/themes → Extension/Theme Manager should allow user-override to install incompatible (wrong version) extensions/themes
This would really save time and the hassle of repacking. Every *.1 casuses the
same problem over and over. And all that needs to be changed is on line...
This pref should also prevent extensions from being disabled when upgrading
Firefox to the next *.1.
I agree 100%.. it is a real pain in the you know what to keep repacking
extensions that work fine anyway! Maybe an option in advanced settings to enable
users to see the yes/no prompt or something
(In reply to comment #6)
> This pref should also prevent extensions from being disabled when upgrading
> Firefox to the next *.1.

I don't know that it should really go that far... it might be a good thing to
still disable extensions on upgrade, just to make sure any problems which arise
are due to the upgrade, and not to the extensions.

The idea of allowing a user-override implies that the user has already upgraded,
and therefor knows the build is usable on its own.
extensions.override.version_check would be a pref that I would support
wholeheartedly; being able to tell Firefox to install extensions with
restrictive maxVersions or minVersions would be useful.
I think this should be available, I don't want to repackage all my extensions
when a new version comes out... And what now happens isn't also good:
Much people are setting the MaxVersion to 5.0 just for not having to update
In the mean time, you can go to this page
http://www.mozilla.org/projects/firefox/extensions/update.html and learn how to
install extensions incompatible with the version of your browser. It is also
explained how to update the maxversion whithout repacking it.
In fact, the option app.extensions.version in config should be used to implement
an interface to the requested feature.
re comment 11: actually, exposing app.extensions.version will not help. Imagine,
extension A has maxversion 0.10, extension B has minversion 1.0. Whatever you
set app.extensions.version to, you won't be able to enable both A and B.

This bug should be about a _new_ pref which says Firefox to ignore compatibility
information for extensions and just install them. It shouldn't be in UI imo.
(In reply to comment #12)
> This bug should be about a _new_ pref which says Firefox to ignore compatibility
> information for extensions and just install them. It shouldn't be in UI imo.

Prefs get saved across sessions -- not a good idea for the kind of user-override
I had in mind.  I don't think this user-override requires any preferences

... unless one wishes to add a pref to disable this proposed override (if
implemented) and preserve the current behavior.

That may be a good compromise between those who think an override like this
would be too dangerous, and those (such as myself) who think an override like
this would be great for added user-control and convenience.  Those who know
enough about what they're doing would probably become aware of such a toggle
pref, and could easily add it to their user.js file and get the override dialog
box when they try to install an 'un-version-bumped' extension... for everyone
else, the current behavior would remain (thus still protecting your 'average'
user who may not really know the possible consequences of what they're doing).
One could add an 'install extension anyway'-button /based on/ a certain pref
(app.extensions.allowversionoverride?) being set to true.
*** Bug 268804 has been marked as a duplicate of this bug. ***
When FF1.0 becames more popular, everybody will start creating extensions. Then,
some extensions will begin to be incompatible, or even dangerous. Then, people
will be afraid of installing extensions.
Extensions should be signed, and their version limits should be enforced. Those
who develop extensions *should* maintain them and are the right people to find
if their extension is compatible with a given FF version. Perhaps there should
be some trusted repository online that could list version compatibilities,
avoiding the need to repackage?
An option to override the security should never be presented to the normal user.
(In reply to comment #16)
> When FF1.0 becames more popular, everybody will start creating extensions. Then,
> some extensions will begin to be incompatible, or even dangerous. Then, people
> will be afraid of installing extensions.
> Extensions should be signed, and their version limits should be enforced. Those
> who develop extensions *should* maintain them and are the right people to find
> if their extension is compatible with a given FF version. Perhaps there should
> be some trusted repository online that could list version compatibilities,
> avoiding the need to repackage?
> An option to override the security should never be presented to the normal user.

I think that such an option would/should be made so that a "normal user" would
never be presented with it.
Ok, I admit, that there may be incompatibility issues and that the avarage user
shouldn't face these. Yet, I would like to point out, that the avarage user WILL
NOT upgrade if he/she wont be able to use the extensions he used in a previous
version. Or worse: he/she upgrades to find out that s/he's not able to use the
favorite theme, and can't make any mousegestures anymore, because of
incompatibility. In this case s/he will choose another browser where after every
upgrade all the fetures s/he is used to are available.

Extension and theme makers should be up to date when a new FF version comes out.
(In reply to comment #18)
>
> Extension and theme makers should be up to date when a new FF version comes out.
>

Some of us were up to date. Many were not, either by choice or by circumstance.

Personally, I would support an override that would allow an extension with a
narrow minVersion-maxVersion range to be installed into a browser falling
outside that range. The only proviso is that it ought to only be able to install
extensions where the minVersion-maxVersion range is _beneath_ the current
version of the browser, not above it.
I spent a whole day trying to get all 25 of my extensions back (yes, I know I
could have repacked them myself, but I thought it waas time to see if there were
any new versions).

I voted for this "bug".
This definitely needs fixing.
I've recently switched over from myIE2 to Firefox but I only did so because I
managed to find extensions that made firefox copy all the features that myIE2
had that I would  have otherwised missed.
Without the extensions I'd never have switched.
I am a power computer user (a system Admin and a web developer) but I do not
want to have to spend my time and effort on my web browser. When a new version
of FireFox comes out, I obviously want to upgrade it to get the latest security
and bug fixes but I dont want to then have to run around for the next hour or
two trying to chase down upgrades to my Extensions or worse still end up without
some of them just because a simple max version value was set to lower than the
new version.
This would COMPLETELY discourage me from ever upgrading as I wouldn't want all
the hassle associated with it.

Putting an option in: about:config - isn't making it visible to the average
user, its letting power users do what they want with their browser which is
exactly what a power user wants.

Another idea would be that upon installing a new version of FireFox - disable
any incompatible extensions for a full day with a notice (as is currently in
place saying they are incompatible). After a day allow the extensions to be
enabled anyway with a warning 'this is not recommended, this extensions are not
checked as compatible with this version of firefox, are you sure you wish to
proceed'.

That way users have one full day to make sure Firefox itself is working properly
and so know it's not a bug with firefox. At that point they can force the
extensions to work anyway if they want and if they notice the browser is acting
strangely they know it is because of an extension they enabled.

If you wanted to doubly be safe - build a check into firefox that if it crashes
more than X times in the first day/two days after extensions are forced to work,
it automatically disables incompatible extensions therefore making itself stable
again.

I really hope this is sorted though otherwise I probably will never upgrade the
browser simple to avoid all the hassle of having to upgrade everything else as
well and this will end up making it even less safe than IE.
A whole day?  I dunno about you, but I can't last a second without AdBlock.  I
say we just give the user a warning: !WARNING! The extensions are you about to
enable may not be compatible with this version of Firefox.  Are you sure you
want to enable them?  Yes/No
There should be disabling on upgrade, to test the clean upgrade first.

There should be a usual warning of possible casualties.

But there should also be a button to bump the maxVersion with one single click.

So we who like experiments can bump maxversions, one by one re-enabling the
extensions to see if something goes wrong.

And, if something goes wrong, one may run Firefox Safe Mode and disable the
incompatible extension back again.

I'll vote for it.
No, this enhancement should not touch any 'maxversion'.  It should just allow
for an user-override of the maxversion restriction at extension/theme
installation.  It should not be going around altering any already-present
configuration bits.

Also, this enhancement is limited *only* to the install time of an extension or
theme (though, 'at enable time' might be nice too).  It has nothing to do with
what happens when the application (Firefox or Thunderbird) is updated.

I just want to keep this bug on focus in terms of its intent.
of the tens of extensions i have hacked to update the maxversion for firefox and
thunderbird, only one was actually incompatible with the new version of the
program. i then just uninstalled the extension. no long term damage.
As reported, this will never be "fixed".  Presenting the user with an option to
install questionable extensions is a Bad Thing(tm).  There just isn't a viable
use-case for exposing this to all users in any form.

Installation is only the first step.  You would also need to disable the
compatibility checking on each restart of the app.  So the only viable option is
to simply turn off compatibility checking for extensions/themes or user-defined
max/min versions, which even as an about:config option seems potentially
dangerous.  If someone wants to spin off a separate bug dealing with a (very)
buried pref to disable the compatibility checking for extensions/themes, that
would be useful to a number of people prepared to potentially sacrifice
stability for convenience.  Please cc me on that bug and note it here so others
can follow something viable.

Keep in mind that the entire version checking scheme only came in for 0.9.  The
changes to APIs etc between 0.9 and 1.0 were trivial and compatible because we
were working on a stable branch.  The jump to 1.1 will quite probably break a
much larger number of extensions.  Themes may be ok to an extent, but 1.5
involves significant changes.  The 2.0 plans are certain to break a fair number
of 1.0-compatible extensions, so just because going from 0.9 to 1.0 wasn't
significant doesn't mean 1.0 to 1.1/1.5/2.0 will be the same.

I realize that there are a significant number of votes on this bug, and some
people will be unhappy, but votes don't make bad decisions into good ones. 
Please feel free to email me with any rational arguments.  Irrational ones will
be handled by Ben Goodger's Complaints Department. (google can be your friend)
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
If you insist on marking this WONTFIX, then the extensions on UMO need to be
updated a lot sooner next time (preferrably before the release). I know four
people who went back to using IE after their extensions failed during the
upgrade from the PR to 1.0. Thankfully, I was able to get three of them to
switch back by pointing them to extensionsmirror.nl. The fourth user still
refuses to try Firefox again. I have to wonder how many people are like him.

I'm sure that someone will try to blame the extension authors or maybe the folks
running UMO, but the end users really don't care. All they know is that Firefox
didn't work like they expected it to. From their perspective, the new version of
Firefox must be broken if it can't even read their old extensions. After all of
the hype about making Firefox grandma-friendly, it sure looks like we shot
ourselves in the foot on this one.
(In reply to comment #27)
> If you insist on marking this WONTFIX, then the extensions on UMO need to be
> updated a lot sooner next time (preferrably before the release). 

This is something that well-maintained extensions should already do, but the new
UMO will make this much easier.

> 
> I'm sure that someone will try to blame the extension authors or maybe the folks
> running UMO, but the end users really don't care. All they know is that Firefox
> didn't work like they expected it to. From their perspective, the new version of
> Firefox must be broken if it can't even read their old extensions. After all of
> the hype about making Firefox grandma-friendly, it sure looks like we shot
> ourselves in the foot on this one.

If we let people install incompatible stuff and it blew up in their face, we'd
look worse (and did, in the past).  "Grandma" doesn't understand "incompatible
extension broke startup" she just thinks "the darn thing don't work" and
switches back to IE.  This is what we had before 0.9.  Trust me, I've read the
bug reports and dealt with the angry people on IRC since 0.6 days.  It sucked. 
This is a mild inconvenience in comparision, and hopefully we'll be able to lock
things down long enough in advance of 1.1 that extension/theme maintainers can
test/upgrade as necessary before release.  But we can only do so much in these
cases.

As someone who had to tell countless early adopters how to manually nuke their
chrome registry because of bad themes/extensions, I don't think that having to
wait a few days after release for extension upgrades represents a significant
problem.  Given that major releases will probably happen every six months or so,
I don't think that a few days' delay in being able to upgrade with numerous
addons is worse than hosing profiles so the app won't start up.
(In reply to comment #28)
> If we let people install incompatible stuff and it blew up in their face, we'd
> look worse (and did, in the past).  "Grandma" doesn't understand "incompatible
> extension broke startup" she just thinks "the darn thing don't work" and
> switches back to IE.

This is why I proposed a 'hidden' preference only available in about:config to
enable such override functionality in the extension/theme manager; and why I
also proposed a *very* prominent warning to the user before doing anything. 
Such things would protect those who need protecting, and allow the desired
flexibility for those who know and understand the risks.

Excluding the option of such control and flexibility implies that Firefox is
*only* being developed with grandma in mind.  And I believe such a path will
alienate those enthusiasts who have helped make Firefox what it is today.  I see
no reason why, as proposed in this instance, Firefox cannot cater to both.
Prominent warnings only work if users read warnings.  Users don't.  Having a
hidden preference in about:config isn't much of a deterrent, since as soon as
the pref gets added, it'll be passsed around as a "tip" and we'll still get bugs
filed.

The only real fix we might consider is turning off compatibility checking,
period.  We're not going to spec/add/test/support a UI solution, even one hidden
by default.  That's kinda bloaty, and since its in effect a hidden pref that
lets you play Russian roulette with extensions, it doesn't seem like something
we want to invest our time in (along with the time of all the localizers who'd
have to translate and test the dialog in their language).

The reality is that this only really matters in possibly the first week after a
new version bump.  Once the extension/theme maintainers catch up, its no longer
necessary.  Having hidden UI and code to handle this type of function, when its
probably useful two weeks out of the year to our user base, just doesn't make
sense.  (For people running nightly builds, well, by running nightlies you're
forsaking any guarantee of anything.  If you can't stand being without your
extensions for a few days, use stable releases only.  That's what they exist for.)
(In reply to comment #30)
> Prominent warnings only work if users read warnings.  Users don't.  Having a
> hidden preference in about:config isn't much of a deterrent, since as soon as
> the pref gets added, it'll be passsed around as a "tip" and we'll still get bugs
> filed.

These sorts of sweeping generalities does nothing but preclude any kind of
constructive discussion.  If what you are claiming were really true, then there
would be no purpose for any kind of user dialogs anywhere, and that's just
silly.  Yes, there are some users who blindly go around being stupid with 'tips'
and such... but these users aren't 'grandma', and they aren't the kinds of
people who would jump ship to IE so easily.  There are a lot of things taht have
to all fall into place anyway for such a situation to arise in the first place.
 No, the sky will not fall if we give users a little bit of control.

> The only real fix we might consider is turning off compatibility checking,
> period.  We're not going to spec/add/test/support a UI solution, even one hidden
> by default.  That's kinda bloaty...

This is an extremist 'solution' and is not practical in any way, shape, or form.
 If that's really "the only real fix we might consider," then I have much deeper
concerns about Firefox than I did 5 minutes ago.  I don't see anyone here
proposing eliminating version checking completely (and it's not 'compatability
checking', since the check only looks at a version number... not whether the
extension/theme is actually compatible).  Your mention of it completely
misrepresents the intent of this enhancement request.

What's being requested is a basic option with similar functionality to a
'-force' command.  Judging from the overwhelming response from both users and
extension/theme creators, it's highly desired from a usability standpoint. 
"That's kinda bloaty" in response to one disabled-by-default dialog box is
really clutching at straws.

> The reality is that this only really matters in possibly the first week after a
> new version bump.  Once the extension/theme maintainers catch up, its no longer
> necessary.

The main issue is with extensions and themes which no longer are being
maintained, or are being maintaned by folks who don't have all the time in the
world to go and update them immediately (staying on top of extensions/themes is
not a full-time job, unfortunately, and many other things may take priority in
an author's life).  Take the 'getmess' extension for Thunderbird... it hadn't
been updated for well over a year, yet still functioned perfectly well for all
that time while Thunderbird went through a great many changes.  Granted, the
functionality of that specific extension has recently been built in to
Thunderbird (as I had been requesting for a long while), but the example still
holds.
If extension authors aren't maintaining extensions, its a crapshoot whether it
will still work.  While some extensions, especially those using frozen
interfaces, will be fine, I'm absolutely certain that themes for 1.0 will need
updates for 1.5/2.0, if not for 1.1.  There's also the reality that moving to
the 2.0 core will involve dropping a lot of old interfaces that we don't want to
maintain in favour of new interfaces.  This definitely includes some frozen
interfaces from 1.x.

As for the "poor overworked extension authors" aspect, UMO-hosted extensions
will soon have a stone-simple process to update maxVersion (change a drop-down
box, hit Submit).  If that's too onerous for them to do a couple times a year,
do we want any form of official support for running these addons?  My opinion is
obviously no.

Fixing this "right" would involve at least the following:

- Allow extensions/themes to be installed even if they fail the version check.
- Track which extensions were installed via the override, including which
version the user overrode the check for.  (Just because you take the chance for
1.1 doesn't mean you will automatically want to take the chance for all
subsequent versions (i.e. 2.0).)  If we don't do this, you'll run into problems
on each startup since we don't just check on install, we check on extension load.
- During the first run of a new version (i.e. 1.1->1.5) allow the user to select
which extensions/themes to override the check for (this will include compatible
addons for 1.1 that fail for 1.5, even if they weren't forced originally)

And there's probably things I'm not thinking of.  This is why I'm saying its
bloaty.  You've glossed over the parts where I've said its more than just
changing the dialog.  There's no value in implementing a partial solution, we'll
do it right, or not at all.  (And if we do it half-assed, we'll just get more
bugs filed on doing the rest of it right.)

As for the "users don't read dialogs" aspect, look at how many people deleted
huge numbers of files using the uninstaller, including some people who answered
yes to "Do you want to delete the folder 'C:\Program Files\' completely?"  (see
bug 233625 for all of the gory details)  If a dialog can hose a user, its better
to just not offer the dialog then hope they'll read it.
(In reply to comment #32)
> Fixing this "right" would involve at least the following:
> 
> - Allow extensions/themes to be installed even if they fail the version check.
> - Track which extensions were installed via the override, including which
> version the user overrode the check for.  (Just because you take the chance for
> 1.1 doesn't mean you will automatically want to take the chance for all
> subsequent versions (i.e. 2.0).)  If we don't do this, you'll run into problems
> on each startup since we don't just check on install, we check on extension load.
> - During the first run of a new version (i.e. 1.1->1.5) allow the user to select
> which extensions/themes to override the check for (this will include compatible
> addons for 1.1 that fail for 1.5, even if they weren't forced originally)

This enhancement bug report is limited to just the first of these three things
you listed.  The second item in your list can already be accomplished by
toggling the extensions.disabledObsolete preference.  And the third item in your
list is something I intentionally left outside the scope of this bug report --
at first run, Firefox should disable all extensions/themes with mismatched
versions; no ifs, ands, or buts -- that bit should stay.  Now, if someone wants
to bump the 'enable' option in the extension/theme manager UI to the same dialog
I proposed for item #1, that's great... but that wouldn't add anything that
could reasonably be considered 'bloat'.

There is already a way to override the version checking to let users install
'old' extensions anyway.  It's just a real tedious pain in the ass if you have
more than 2 or 3 'old' extensions to install.  This proposed enhancement won't
be allowing anything that's currently impossible... it will only be making
things more convenient and less of a time-consuming headached for those of us
who are going to install these things anyway.
And what if someone just makes an external application that can change the
max-version of one or more extensions with one click?
(In reply to comment #33)
> This enhancement bug report is limited to just the first of these three things
> you listed.  

What part about "if we're going to do this, we're going to do it right or not at
all" wasn't clear?  Allowing a user to override the install is useless if you
need a second pref to actually USE the extension/theme.  As a note:
extensions.disabledObsolete, based on reading the code, only deals with
disabling the 0.8-style extensions on first startup.  It has nothing to do with
turning off checking for new-style extensions.  (And the code only executes if
the value isn't true, after which it gets set to true.)

And if you disable all incompatible extensions on upgrade, then either you need
to uninstall all of your extensions and do the install, or you have to have a
way to enable incompatible extensions.  Again, this goes to the "do it right or
not at all" bit, which we're not going to deviate from.
(In reply to comment #35)
> What part about "if we're going to do this, we're going to do it right or not at
> all" wasn't clear?

How rude.  I'd appreciate it if your tone became a bit more civil.
I took the time to explain why the other two items in your 3-point list weren't
really necessary to this enhancement request.

> Allowing a user to override the install is useless if you
> need a second pref to actually USE the extension/theme.  As a note:
> extensions.disabledObsolete, based on reading the code, only deals with
> disabling the 0.8-style extensions on first startup.  It has nothing to do with
> turning off checking for new-style extensions.  (And the code only executes if
> the value isn't true, after which it gets set to true.)

I have not looked at the code for the preference, but I know that I have a
number of 'old' extensions installed which never get disabled at Firefox load
(as you say happens).  And I know that preference helps in some manner, though
that specific manner I cannot recall, as it's been quite a while since I set it
from 'true' to 'false' (and it's stayed 'false'... so I don't know that I
believe 'false' triggers a process which ends up setting it to 'true').

> And if you disable all incompatible extensions on upgrade, then either you need
> to uninstall all of your extensions and do the install, or you have to have a
> way to enable incompatible extensions.  Again, this goes to the "do it right or
> not at all" bit, which we're not going to deviate from.

Not arguing with that... I said bumping the 'enable' option to the same dialog
box would be nice (not to mention an efficient use of UI elements -- i.e., not
added bloat).  What I was saying is that at the time of Firefox/Thunderbird
install, all 'old' extensions/themes should be disabled.  An option to allow
these extensions/themes again should not be given until afterwards, and should
be independant of the FF/TB installation proceedure.  That's different than what
you were saying in your 3-point list.

(In reply to comment #34)
> And what if someone just makes an external application that can change the
> max-version of one or more extensions with one click?

I think it would be best to preserve the original max-versions of
extensions/themes, and the max-version of the program.  Were this sort of
enhancement implemented (via extension or otherwise), a non-intrusive form would
be ideal.

But an extension which would allow for a selective bypass of the version
checking test without actually altering any part of the extension would be an
adequate solution.  A solution wouldn't necessarily have to be built in to the
default program (in theory, at least -- I don't know enough about the workings
of the actual code to know whether such a thing is realistically feasible).
Why not introducing a capability vector which is returned by each plugin?
This could be a bitvector which describes what api/interface a plugin really
needs. So FF/Moz can check if the plugin still runs or if the plugin has to be
disabled because of a changed interface api.

In my opinion just a simple version number check does not really solve
compatibility problems.
Well... if extensions could do adequate checking of APIs etc, that wouldn't
necessarily fix all cases (i.e. using an entity for a text string that we end up
removing in a component rewrite will break a window that gets overlaid).

(In reply to comment #36)
> (In reply to comment #35)
> > What part about "if we're going to do this, we're going to do it right or not at
> > all" wasn't clear?
> 
> How rude.  I'd appreciate it if your tone became a bit more civil.
> I took the time to explain why the other two items in your 3-point list weren't
> really necessary to this enhancement request.

First off, the fact that I'm continuing to respond in good faith despite my
belief that this is a uselses enterprise is a pretty big step.  Ben or blake
probably wouldn't even bother.  And in taking that time, you ignored my
statement that allowing user-override of compatibility checking (with warnings)
would either be done in a complete form or not at all.  We don't do "partial"
solutions where we have a choice.  Part 2 would be necessary, since you're
making a bad assumption about a second pref (see below).  Also, requiring a
second pref is a bad idea in general (allowing installation but not use makes
zero sense, so two prefs is a bad idea).  As for part 3, if we're going to tell
a user that extension Y is not compatible, and let them check for updates, it
makes no sense to then disable it, and force them to go back and manually enable
each extension.  We should present the option then and there, and let them get
on with things. Anything else is inflicting a heavier burden on the user than is
desired, since this is about removing tedium and time-consuming tasks, after all.

You may only want part 1 (and a working part 2, see below), but all would be
necessary for me to accept this as a valid feature.  You're welcome to disagree
with this, but that's the way it is.

As for the disabledObsolete pref, if you manually set it to something (via
user.js etc) it handles that as true.  You can set it to "2314123" and we'll
still skip the disabling.  Old-style extensions (pre-0.9) don't get touched by
the compatibility checker.  On the first run of a build with extension manager,
we automatically disable all older extensions.  If you enable them again they
will not be disabled again.  This has no bearing on any extension that utilizes
maxVersion, as I said.  You might think it does, but the actual code that is
controlled by the pref is quite clear.  If a developer says that the code does
X, don't try to assert that it does Y without even looking at the code.
> (In reply to comment #36)
> First off, the fact that I'm continuing to respond in good faith despite my
> belief that this is a uselses enterprise is a pretty big step.  Ben or blake
> probably wouldn't even bother.

'Good faith' does not imply such rude and condescending behavior as you have
been displaying.  My appologies for not realizing how utterly lucky a lowly
user, such as myself, am that you 'bother' to respond (no matter what level of
civility it may be).  I think the Mozilla team's PR efforts need a bit of work.

> And in taking that time, you ignored my
> statement that allowing user-override of compatibility checking (with warnings)
> would either be done in a complete form or not at all.

I ignored nothing.  In comment #33 I clearly addressed each of the three points
you said would be needed in a 'complete' fix.  You may disagree, but that does
not mean that I ignored anything.

> Part 2 would be necessary, since you're
> making a bad assumption about a second pref (see below).

Yeah, I probably was, but I do know from experience that if I force an install
of extensions limited to version 0.91 on the 1.0 release (by changing the
version number in about:config), they don't get disabled each time Firefox runs
after I chage the FF version back.  So, I don't see how part 2 is necessary.

> Also, requiring a
> second pref is a bad idea in general (allowing installation but not use makes
> zero sense, so two prefs is a bad idea).

Yes, it is.  But it was a preference that was already present, and adding
anything else to do the same thing would be redundant -- which I'd argue is a
bit worse.

> As for part 3, if we're going to tell
> a user that extension Y is not compatible, and let them check for updates, it
> makes no sense to then disable it, and force them to go back and manually enable
> each extension.  We should present the option then and there, and let them get
> on with things. Anything else is inflicting a heavier burden on the user than is
> desired, since this is about removing tedium and time-consuming tasks, after all.

I disagree.  After a Firefox/Thunderbird upgrade, I feel it's important for the
program to disable such extensions initially so that it may be established that
the program runs correctly on its own (see comment #8).

> As for the disabledObsolete pref...
> If a developer says that the code does
> X, don't try to assert that it does Y without even looking at the code.

It was an educated guess, and I take your word for it that the code does what
you said.  I was never arguing that it did X after you said the code did Y.  I
said "and I know that preference helps in some manner, though
that specific manner I cannot recall," because changing it had helped me get
past some version issue or another a great many months ago, but it had been so
long that I didn't remember if it was truly the same kind of issue as this.  And
I questioned the 'it then gets set to true' bit because that was before you said
it is treated as true if manually set to false.

This enhancement request is not intended to make anything easily accessible to
the average user (to 'grandma').  It's intended to make something more
convenient for those of us who like playing with software, who can stand some
instability every once in a while, who enjoy testing out nightly builds with
different combinations of extensions.

This enhancement would not be for the mainstream, so a quick-n-dirty development
toggle would be just fine.  There's quite a bit people can hose already when
changing about:config preferences, so I don't quite see why one more (that is so
desired as this one, and with such a clear warning to the user) is so much worse
than all the others to be quickly blacklisted as 'too dangerous'.

The capability to force an install of 'old' extensions/themes is already there.
 Not adding this enhancement would stop anyone from doing the same thing anyway
-- it just takes longer, has numerous tedious steps, and opens the door for
significantly more user-error and program-hosing than this enhancement would.
Fishbert,

With all due respect, you don't seem like a programmer to me.  You seem like one
of those people who says, "I want my computer to do my dishes", and doesn't
realize that as simple as that may be for you, it's a nightmare for a computer
or its programmer.

Consider this; Mike Connor is one of the programmers of very popular and very
good software; if you don't think he's a busy man, you're crazy.  I do consider
his taking the time to even bother with you indeed a gift... many in his
posisition would send some PR or QA person at you and never think of it again.

This is bugzilla.  This isn't for talking to the PR people, or the QA people, or
the support people, or anything like this.  You're talking to the developers. 
And if you insult them, they don't have an obligation to take it in stride, and
continue to work with you.  Those other groups of people do, but not developers.
 It's not part of their job description.  It's like asking a grave digger to
have a good bedside manner.

For my part, I write forum software.  Not anything nearly as popular as Mozilla,
but there are "mods" (extensions) made for it, and version checking.  And, this
exact "enhancement" has been requested for it as well - you can believe I
immediately said "wontfix" myself.  As much as you assert that gradmas wouldn't
be using it, they'd have their grandchildren over once, and bam... next upgrade,
the browser is an error message and a pile of dust.

I've seen it before when the betas and earlier versions of the software I write
had not checking.  People, like you, hate updating things... hate not having an
extension for even two days, so they will do everything in their power to make
the browser or software product cease functioning completely.  And then, they
will be far too embarrassed to ever ask for support; because they messed it up.

I agree it would be nice to have a pref to do what you're wanting, but please
realize two things: one, it is more complex than you think, just as Mike Connor
is asserting... and two, it will be abused if added.

An unofficial, third-party tool to reset the maxVersion would solve some of
these problems, and not make Mozilla look bad when it causes problems.  It would
also go hand in hand with your assertion that this functionality is not meant
for the mainstream.

Again, forgive me if you don't like being disagreed with, and I'm not trying to
insult you or feed the flames at all.

-[Unknown]
(In reply to comment #41)
> Fishbert,
>
> With all due respect, you don't seem like a programmer to me.  You seem like one
> of those people who says, "I want my computer to do my dishes", and doesn't
> realize that as simple as that may be for you, it's a nightmare for a computer
> or its programmer.

I have done quite a bit of programming, actually.  Just nothing to do with
Mozilla.  I filed this bug report in the role of a 'power user' who doesn't feel
he needs to be protected from his software -- who wants a bit more control than
grandma.  And I'd hardly equate something as relevant, desired, and useful as
this enhancement request to 'I want my computer to do the dishes'.

> Consider this; Mike Connor is one of the programmers of very popular and very
> good software; if you don't think he's a busy man, you're crazy.  I do consider
> his taking the time to even bother with you indeed a gift... many in his
> position would send some PR or QA person at you and never think of it again.
>
> This is bugzilla.  This isn't for talking to the PR people, or the QA people, or
> the support people, or anything like this.  You're talking to the developers.
> And if you insult them, they don't have an obligation to take it in stride, and
> continue to work with you.  Those other groups of people do, but not developers.
>  It's not part of their job description.  It's like asking a grave digger to
> have a good bedside manner.

I don't believe I have insulted developers in requesting this enhancement.  I
did take exception to what I felt was an insulting mannerism from Mr. Connor,
but even in responding to that, I think I was completely civil.  If I have
somehow unintentionally insulted him in any way, I'm sorry, that was never my
intent.  Though I do also feel I deserve the same apology from him.

If the developers are interfacing with the user base for a product, then
personal relations becomes a part of their job description.  People get turned
off by condescending tones and high-horsedness.  And that reflects poorly on the
project; no matter who in the organization it comes from.

> For my part, I write forum software.  Not anything nearly as popular as Mozilla,
> but there are "mods" (extensions) made for it, and version checking.  And, this
> exact "enhancement" has been requested for it as well - you can believe I
> immediately said "wontfix" myself.  As much as you assert that gradmas wouldn't
> be using it, they'd have their grandchildren over once, and bam... next upgrade,
> the browser is an error message and a pile of dust.

I completely agree that's likely to happen.  That's why I said that I think
asking users about version overrides when FF/TB is upgraded is a bad idea (part
3 in Mr. Connor's list).

> I've seen it before when the betas and earlier versions of the software I write
> had not checking.  People, like you, hate updating things... hate not having an
> extension for even two days, so they will do everything in their power to make
> the browser or software product cease functioning completely.  And then, they
> will be far too embarrassed to ever ask for support; because they messed it up.
> I agree it would be nice to have a pref to do what you're wanting, but please
> realize two things: one, it is more complex than you think, just as Mike Connor
> is asserting... and two, it will be abused if added.

There already is a pref to do what I'm wanting -- the pref storing the FF/TB
version being checked against.  The trouble is that such a thing has to be
changed multiple times to accommodate different extensions/themes.  And, I'm not
terribly comfortable with the idea of touching the internal version number of a
piece of software -- people may forget to set it back, or perhaps reset it to an
incorrect value which they think is what it originally was; and that may cause
problems down the road.

> An unofficial, third-party tool to reset the maxVersion would solve some of
> these problems, and not make Mozilla look bad when it causes problems.  It would
> also go hand in hand with your assertion that this functionality is not meant
> for the mainstream.

Yes, a third-party tool would be great.... but again, I'm not sure that touching
the maxVersion is really the correct way to go about it.

> Again, forgive me if you don't like being disagreed with, and I'm not trying to
> insult you or feed the flames at all.

Not at all.  I don't mind disagreement if it's done in a cooperative (rather
than dismissive) manner. =)
It's my hope that this will all lead to some kind of an acceptable solution --
be it through a bug fix, a third-party option, or something else entirely.  For
this is a very popular enhancement request (judging by the votes), and it would
be a shame to have the idea die completely.
Nobody has insulted anybody, this is just one of the unpopular decisions that
has been made for the greater good that many power users (myself included) will
not like. I've often been on the wrong end of these sort of decisions, but I've
learned to live with them. The browser won't always do exactly what you or I
want it to and will never be all things to all people. Being all things to all
people was what Seamonkey tried to do, and we know that Firefox sells better
than Seamonkey.

Kevin, I realise that this is a feature that you'd like to see. I fully
understand your rationale for it. But understand also that creating UI (hidden
or not) to disable version checking is going to be abused by users who will
blame Firefox for their screwups. Since that is a given, we'd like to avoid that
situation entirely.

So, let's accept this decision and move on. Frankly, I'm convinced that this is
not going to be reopened, so if you'd like to see this functionality, look into
other means of providing it (I don't know how, but this is not the right forum
to discuss that).

A better thing to concentrate on would be enhancing the extension API such that
extensions can't screw up Firefox so badly that even Safe Mode doesn't work.
Let's fix the API, not patch around these minor annoyances.
(In reply to comment #43)
...
> A better thing to concentrate on would be enhancing the extension API such that
> extensions can't screw up Firefox so badly that even Safe Mode doesn't work.
> Let's fix the API, not patch around these minor annoyances.

:-)
Blocks: majorbugs
No longer blocks: majorbugs
*** Bug 308031 has been marked as a duplicate of this bug. ***
Just curious, as someone whose bug 311998 is probably about to be marked a dupe
of this one.  Has anyone considered an extension-validity check based not on the
browser version, but on the version of the API or APIs which the extension makes
use of?  So that extension which will work just fine will work just fine,
without requiring the extension developer to notice that there's a new browser
release, go to UMO and click the "yes, my fricking extension works, dumbass"
checkbox and hit submit every month or two, when that developer might very well
be on vacation the week the new browser release happens.  It seems particularly
like extensions which only use frozen APIs ought not to be hosed every time
there's an emergency security bugfix release...  As Mike said in comment #32:
"...some extensions, especially those using frozen
interfaces, will be fine..."
Just in case somebody has not found this yet:

Nightly tester tools
https://addons.mozilla.org/extensions/moreinfo.php?id=958

Gives you a magical button that says "make all compatible" in the Extensions dialog

If it was up to me, it would be part of FF/TB, but I realize that bug would be marked as WONTFIX quicker than I could post it.
I think that overriding extension version checks in general is too heavy a hammer to give away for everyone. Or rather, I do not think any tool should be access-restricted. I think providing a more specific, easy to manage tool and making that more visible is a good thing.


I often wonder what "WONTFIX" means in an open-source project. If a community member will fix it, is it "WONTFIX"? Should that be "WILL NOT FIX" or "WE KNOW BETTER THAN YOU"? :-)
Product: Firefox → Toolkit
As for bug 251148 I think this bug should be marked as WORKSFORME or DUPLICATE of Bug 330895 ?
You need to log in before you can comment on or make changes to this bug.