521905 - Make extensions.checkCompatibility be per-application-version

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect, P2)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

When a user tests a new version of Firefox, he may choose to turn add-on compatibility off. Perhaps he read a helpful article, or perhaps he's actually testing if an add-on is compatible.

When that user is then upgraded to the *next* version of Firefox, though, they should be required to make the decision about automatic compatibility checking again, as the context has changed. This will also help to avoid crashes with well-meaning add-ons which have not yet marked themselves as compatible.

I strongly recommend that whenever a version change is detected, we automatically reset extensions.checkCompatibility to false (if the pref exists)

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Sam asked "what do you mean by version?" which is a good question.

I mean any minor or major numerical change. So:

 3.0 -> 3.5
 3.5 -> 3.5.1
 3.5.3 -> 3.6

etc

Comment 2

[u88484]

I think it should only be major updates.

Comment 3

[Jesse Ruderman]

This could cause problems for users who switch between Firefox 3.5 and Firefox 3.6 betas frequently.

Comment 4

[Benjamin Smedberg]

I recommend that we use the following scheme:

extensions.checkcompatibility.<version> = true/false

That way you can keep the override for a version if you switch-hit branches, but you have to explicitly choose the override for new versions.

Comment 5

[(not currently active) Ted Mielczarek]

Re-setting equivalent flags.

Comment 6

[Justin Dolske [:Dolske]]

(In reply to comment #4)

> extensions.checkcompatibility.<version> = true/false

One possible downside of that would be having people just blindly set the pref for future versions, so that they don't get annoyed in the future.

Comment 7

[Justin Dolske [:Dolske]]

Also, filed bug 522111 for the apparently much-discussed-but-never-filed idea of ignoring extensions.checkcompatibility for extensions with binary components. That would be a lower-touch change that still helps with crash problems (though obviously not with non-binary extensions that cause other forms of breakage with newer browser releases).

Comment 8

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm fine with comment #4, we just need to fix this before we ship.

Comment 9

[Dave Townsend [:mossop]]

Attachment: patch rev 1

This preprocesses the gecko version into the preference name. Since we have tests that check the behaviour of this pref it also stashes that version in a convenient js file which can be loaded into tests that need it. I think those tests are also sufficient to verify that this change is working.

There are a few other uses of extensions.checkCompatibility in other test suites in the tree that I'm looking into.

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 408870 [details] [diff] [review]
patch rev 1

>+  gPrefs.setBoolPref("extensions.checkCompatibility." + MILESTONE, true);

Can we have this only change on release milestones, not development milestones? So:

change for:
 1.9.2
 1.9.2.1
 1.9.2.2
 ...

do not change for:

 1.9.2a1
 1.9.2b1
 1.9.2b1pre
 1.9.2b2pre
 1.9.2rc1pre
 ...

Comment 11

[Robert Strong (they/them - no direct email)]

Comment on attachment 408870 [details] [diff] [review]
patch rev 1

Just talked with Dave and he is going to update the patch per beltzner's comments so clearing review.

Comment 12

[Benjamin Smedberg]

How do we do that? Strip out the letters from the version number? What value do we check for development milestones?

Comment 13

[Robert Strong (they/them - no direct email)]

How about any version number with a pre in it just use the existing pref and milestone versions use the pref with the version? I suggest that we do this for alpha and beta builds since they have a wider audience though we might choose not to in order to identify crashes caused by add-ons during the alpha / beta. So,

1.9.2   = "extensions.checkCompatibility.1.9.2"
1.9.2.1 = "extensions.checkCompatibility.1.9.2.1"
etc. and

1.9.2a1 = "extensions.checkCompatibility.1.9.2a1" or "extensions.checkCompatibility"
1.9.2b1 = "extensions.checkCompatibility.1.9.2b1" or "extensions.checkCompatibility"
etc. and

1.9.2a1pre  = "extensions.checkCompatibility"
1.9.2b1pre  = "extensions.checkCompatibility"
1.9.2rc1pre = "extensions.checkCompatibility"

Nightly users don't really benefit from this since the breakage of extensions rarely happens during a nightly version change.

btw: I talked with Dave about munging the values in python.

Comment 14

[Dão Gottwald [:dao]]

I second comment 2. The user needs to reconsider his choice when moving from Firefox 3.0 to 3.5 if an extension is compatible with 3.0.*. For 3.5.0 -> 3.5.1 this doesn't seem to apply.

Comment 15

[Dave Townsend [:mossop]]

(In reply to comment #12)
> How do we do that? Strip out the letters from the version number? What value do
> we check for development milestones?

I was intending to strip off everything from the first letter onwards so 1.9.2b1 -> 1.9.2

Comment 16

[Justin Dolske [:Dolske]]

I also think that security updates should be immune to this, though I don't feel strongly about it (and at first glace it seems tricky to implement that way).

Though I am wary that annoying users on security updates will result in them just pre-clearing the next dozen releases by setting a bunch of prefs -- and then this bug is back to square one. So maybe we should also clear the pref for the next release to make that not work!

Comment 17

[Dave Townsend [:mossop]]

(In reply to comment #16)
> I also think that security updates should be immune to this, though I don't
> feel strongly about it (and at first glace it seems tricky to implement that
> way).

Anything I can think of is pretty fragile. Short of hardcoding the branch alongside the actual version I'd be worried about assumptions we make breaking in the future.

Comment 18

[Dave Townsend [:mossop]]

Attachment: patch rev 2

Here is a patch based on bsmedbergs plan from IRC. Firstly it uses the application version not the gecko version since applicatiosn can and do make major changes to their UI without changing the gecko they are based on. This means we have to do everything at runtime. Secondly it just uses 2 version parts including whether the second part has any alpha, beta or anything else in it.

This works out like this:

3.6a1 -> extensions.checkCompatibility.3.6a
3.6b1 -> extensions.checkCompatibility.3.6b
3.6b2 -> extensions.checkCompatibility.3.6b
3.6 -> extensions.checkCompatibility.3.6
3.6.1 -> extensions.checkCompatibility.3.6
3.6.1b1 -> extensions.checkCompatibility.3.6

So the pref changes when switching from alpha to beta to release during the main branch development and then remains the same during all security releases.

Comment 19

[Samuel Sidler (old account; do not CC)]

(This is probably because I wasn't following this bug well, but...)

I think we actually *want* the pref to change during security releases. We're seeing a number of crashes in 3.5.x that are from users of old add-ons that must have this pref disabled. See also comment 1 where beltzner clarifies.

Comment 20

[Dão Gottwald [:dao]]

(In reply to comment #19)
> (This is probably because I wasn't following this bug well, but...)
> 
> I think we actually *want* the pref to change during security releases. We're
> seeing a number of crashes in 3.5.x that are from users of old add-ons that
> must have this pref disabled. See also comment 1 where beltzner clarifies.

Crashes on 3.5.x that wouldn't occur with 3.5.[x-1]?

Comment 21

[Dave Townsend [:mossop]]

(In reply to comment #20)
> (In reply to comment #19)
> > (This is probably because I wasn't following this bug well, but...)
> > 
> > I think we actually *want* the pref to change during security releases. We're
> > seeing a number of crashes in 3.5.x that are from users of old add-ons that
> > must have this pref disabled. See also comment 1 where beltzner clarifies.
> 
> Crashes on 3.5.x that wouldn't occur with 3.5.[x-1]?

We've certainly seen security releases cause extensions to start crashing, mainly where binary components are concerned.

Comment 22

[Dão Gottwald [:dao]]

Isn't the compatibility-breaking update or the 3.5.* maxVersion the real problem there?

Comment 23

[Jesse Ruderman]

Also, we don't want security updates to be so disruptive that users turn them off.

Comment 24

[Robert Strong (they/them - no direct email)]

Comment on attachment 409971 [details] [diff] [review]
patch rev 2

Talked with Dave about this and he is going to clarify what the behavior should be before the review.

Comment 25

[Mike Beltzner [:beltzner, not reading bugmail]]

I take Sam's point that users who turned off compatibility checking early in a Firefox release's lifespan (ie: 3.6.0 or 3.6.1) may have done so because they so desperately wanted their Add-ons to work. It's entirely possible that by Firefox 3.6.3 all their Add-ons would now be compatible, and that it's more responsible for us to reset that preference, but without being able to guarantee that I am more worried about the users' reaction to having their Add-ons disabled with security updates, as Jesse points out in comment 23.

I think turning it off between major releases is a strong start, and if we want to go stronger, we can do so after the fact. For example, we could file a follow up that, on an update, checks to see if the user has any installed Add-ons which are incompatible; if not, the preference can be flipped for the user without any negative effect.

Mossop: the behaviour as described in comment 18 is fine; let's do it (and perhaps file that followup I suggested?)

Comment 26

[Johnathan Nightingale [:johnath]]

(In reply to comment #25)
> I take Sam's point that users who turned off compatibility checking early in a
> Firefox release's lifespan (ie: 3.6.0 or 3.6.1) may have done so because they
> so desperately wanted their Add-ons to work. It's entirely possible that by
> Firefox 3.6.3 all their Add-ons would now be compatible, and that it's more
> responsible for us to reset that preference, but without being able to
> guarantee that I am more worried about the users' reaction to having their
> Add-ons disabled with security updates, as Jesse points out in comment 23.
> 
> I think turning it off between major releases is a strong start, and if we want
> to go stronger, we can do so after the fact. For example, we could file a
> follow up that, on an update, checks to see if the user has any installed
> Add-ons which are incompatible; if not, the preference can be flipped for the
> user without any negative effect.
> 
> Mossop: the behaviour as described in comment 18 is fine; let's do it (and
> perhaps file that followup I suggested?)

Not that this is really required for progress to be made, but since I've been having conversations with Mossop on the side about it as well: I agree with basically all of this.

Binding the pref to major.minor seems preferable to major.minor.security for a couple reasons, and is already a huge step forward. Cleverly flipping the pref when we determine it's no longer needed is also an idea we should discuss but not one that should block this bug.

Also: Woo.

Comment 27

[Robert Strong (they/them - no direct email)]

Dave, this will also have the behavior of
3.6.1.1 -> extensions.checkCompatibility.3.6

is this really what you want?

Comment 28

[Dave Townsend [:mossop]]

(In reply to comment #27)
> Dave, this will also have the behavior of
> 3.6.1.1 -> extensions.checkCompatibility.3.6
> 
> is this really what you want?

Benjamin's suggestion was just to keep two version parts in the pref since we only use 3 and we don't want the security release in there, so I think that is what we want.

Comment 29

[Robert Strong (they/them - no direct email)]

Comment on attachment 409971 [details] [diff] [review]
patch rev 2

Looks good... I only did a quick review of the tests though.

Comment 30

[Dave Townsend [:mossop]]

Just realised there is one snag with this. Firefox won't make installed extensions incompatible until users switch to a different version, so branch nightly testers would only see it when the branch version jumps from 2.6b2pre to 3.6b3pre for example. I don't think this is a major deal though.

I'm going to blog about this today and then land tomorrow to give nightly users a bit of warning.

Comment 31

[Dave Townsend [:mossop]]

Landed on trunk: http://hg.mozilla.org/mozilla-central/rev/487eed7454d4

Comment 32

[Dave Townsend [:mossop]]

Pushed to branch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/0657cd0ab681

Comment 33

[WildcatRay]

Out of curiosity, will extensions.checkCompatibility remain but be nonfunctional? When I reset it after adding extensions.checkCompatibility.3.6b in Namoroka Branch, it changed to true. (I guess I half expected it to go to blank.)

Comment 34

[Dave Townsend [:mossop]]

(In reply to comment #33)
> Out of curiosity, will extensions.checkCompatibility remain but be
> nonfunctional? When I reset it after adding extensions.checkCompatibility.3.6b
> in Namoroka Branch, it changed to true. (I guess I half expected it to go to
> blank.)

You probably only see this because you have some extension installed that is defining some default for extensions.checkCompatibility. Maybe Mr Tech or Nightly Tester Tools. You shouldn't see this with a clean profile even before this change.

Comment 35

[WildcatRay]

(In reply to comment #34)
> (In reply to comment #33)
> > Out of curiosity, will extensions.checkCompatibility remain but be
> > nonfunctional? When I reset it after adding extensions.checkCompatibility.3.6b
> > in Namoroka Branch, it changed to true. (I guess I half expected it to go to
> > blank.)
> 
> You probably only see this because you have some extension installed that is
> defining some default for extensions.checkCompatibility. Maybe Mr Tech or
> Nightly Tester Tools. You shouldn't see this with a clean profile even before
> this change.

I had added it myself (I'd expect not to see it on a new profile.)

Comment 36

[Matthew Turnbull [Bluefang]]

IMHO, as a trunk tester, this is going to be a PITA. One of the nice things about extensions.checkCompatibility was that you could set it and forget it. And I know I'm going to forget about it next time a version bump rolls around.

Also, having a preference for each version seems rather clunky and a pain to deal with. Wouldn't a better solution be to use a string preference (i.e. extensions.disableCompatibilityCheck or extensions.checkCompatibility.disable) and have the value be the version?

I see 2 advantages for this:
-- It's much easier to change
-- It could allow for more flexible version information and/or wild cards 

For example
-- 3.6 should also satisfy 3.6a and 3.6b
-- 3.6.1 would only be applicable to that version
-- * should be for all versions.

Comment 37

[Dave Townsend [:mossop]]

(In reply to comment #36)
> IMHO, as a trunk tester, this is going to be a PITA. One of the nice things
> about extensions.checkCompatibility was that you could set it and forget it.
> And I know I'm going to forget about it next time a version bump rolls around.

Well that is partly the point. It was set and forget and means people don't
remember they are exposing themselves to incompatible add-ons unnecessarily. I
imagine you won't forget about it when you start a new version of Firefox and
it tells you some of your add-ons have been disabled for being incompatible.

> Also, having a preference for each version seems rather clunky and a pain to
> deal with. Wouldn't a better solution be to use a string preference (i.e.
> extensions.disableCompatibilityCheck or extensions.checkCompatibility.disable)
> and have the value be the version?
> 
> I see 2 advantages for this:
> -- It's much easier to change
> -- It could allow for more flexible version information and/or wild cards 
> 
> For example
> -- 3.6 should also satisfy 3.6a and 3.6b
> -- 3.6.1 would only be applicable to that version
> -- * should be for all versions.

Allowing wildcards just means that that is what people will use leaving us back
in the place we were and only allowing a single version is less flexible than
what we have now.

Comment 39

[Veritas]

this is seriously the worst idea ever.  the ONLY people that are setting this are people that generally speaking are fully aware that they have it set. and any time you open the add-on preferences, it reminds you that it is disabled.  what on earth was wrong with it?...........

Comment 40

[Johnathan Nightingale [:johnath]]

(In reply to comment #39)
> this is seriously the worst idea ever.  the ONLY people that are setting this
> are people that generally speaking are fully aware that they have it set. and
> any time you open the add-on preferences, it reminds you that it is disabled. 
> what on earth was wrong with it?...........

Before other people come in here to indulge you (which they will, because they try to make people happy, they actually dedicate their considerable talents and time to making the best browser they can) I wanted to ask: when you wrote this comment, were you thinking to yourself that:

a) no one in the firefox development community had considered how this was currently used, and
b) that your comment here would be the enlightenment needed to help everyone see that?

I ask because it sounds a lot like a rant that isn't looking for an actual reply - just a grumpy way of expressing disagreement, and I'm wondering why you thought that was productive, and in keeping with our etiquette guidelines (https://bugzilla.mozilla.org/page.cgi?id=etiquette.html).

Comment 41

[WildcatRay]

Perhaps I missed this in the comments, but I wonder if any thought was given to resetting the original pref to true (check for add-on compatibility) on major version changes. On the surface, it would seem to be a quick way to accomplish this. However, I do not know if it would be practical to do as part of the update/installation process.

Comment 42

[Veritas]

@nightingale, 

i've been doing testing on FF since phoenix.  reading through all of the comments (which i did before posting), i don't think that any real thought was given to the fact that it seems to have worked fine since the creation of this setting.  to me, almost the entirety of this conversation on this bug was swamped by group think, and thus my comment was intended to spark some sort of actual debate as to whether this was desirable.

I should add that this has been the normal behavior of extensions.checkCompatibility since it was first created more than 3 years ago.

Comment 43

[u88484]

It works fine for us that know what the hell we are doing.  There are probably hundreds of sites on the internet that freely tell end users to change this setting and the users forget that they have set this...not that they ever even completely understood what the heck this preference done in the first place.

And just because you have been testing since Phoenix, that doesn't mean you spend time on IRC/SUMO/Mozillazine and other random forums throughout the internet and see all of the problems that the old preference has caused for end users.

Comment 44

[(not currently active) Ted Mielczarek]

In his defense, I will note that this bug does not call out the motivation behind this change very well. To wit: we have lots of empirical data (crash reports) that show that people crash a lot by flipping the extensions.checkCompatability pref when they have incompatible extensions with binary components. In the run up to Firefox 3.0's release, Google Desktop (or was it Toolbar?) was one of our *top 10 crashes* for this reason. Clearly there are lots of people who set this preference and do not recognize the consequences. The point of this change is to try to mitigate that experience, at least during upgrades to a new major version.

Comment 45

[Dave Townsend [:mossop]]

(In reply to comment #41)
> Perhaps I missed this in the comments, but I wonder if any thought was given to
> resetting the original pref to true (check for add-on compatibility) on major
> version changes. On the surface, it would seem to be a quick way to accomplish
> this. However, I do not know if it would be practical to do as part of the
> update/installation process.

That was the original intention of the bug, but as noted in comment 3 that would cause real problems for people who frequently flip between branches for testing.

Comment 46

[WildcatRay]

(In reply to comment #45)
> (In reply to comment #41)
> > Perhaps I missed this in the comments, but I wonder if any thought was given to
> > resetting the original pref to true (check for add-on compatibility) on major
> > version changes. On the surface, it would seem to be a quick way to accomplish
> > this. However, I do not know if it would be practical to do as part of the
> > update/installation process.
> 
> That was the original intention of the bug, but as noted in comment 3 that
> would cause real problems for people who frequently flip between branches for
> testing.

I see. (Of course, "experienced" testers should know not to use the same profile for different branches and trunk. I have Fx, 3.6b Branch and Trunk. Each has its own profile. The only commonality aside from add-ons is I keep my data synced with Weave.)

Comment 47

[Veritas]

@kurt

I still don't see how users "forget" that they set this.  every single time you open the add-ons dialogue you are reminded that you are not checking for compatibility.

I do spend some times on those forums, although admittedly not as much as others probably do.  I still question whether it is this setting which causes the problem, or PEBKAC issues...  I don't particularly believe that the devteam ought to feel itself responsible to prevent uneducated users from poking themselves in the eye with a setting they don't understand.

@ted

thanks for the further information.  do you have any way of gleaning from the data whether the people that were experiencing crashes attempted to click "enable" on compatibility checking?  as noted above, at some point I don't think it is the responsibility of the devs to prevent PEBKAC problems.  It isn't like this setting is made particularly available to un-educated end-users.  Yes, there are forums that suggest that people do it, but the "super user" who thinks s/he understands what he is doing and doesn't is not much of a concern.

---------
either way, i think the bigger annoyance here was that it all of a sudden changed without warning.  I might suggest to add a line to the kb article on extensions.checkCompatibility that the behavior has changed and an explanation of how to use it.  as it was, the only way i found out about this was lodging a separate bug because my search of bugzilla didn't turn this bug up.  props, however, to the user that marked my bug as a dupe of this.

Comment 48

[(not currently active) Ted Mielczarek]

(In reply to comment #47)

> @ted
> 
> thanks for the further information.  do you have any way of gleaning from the
> data whether the people that were experiencing crashes attempted to click
> "enable" on compatibility checking?

bug 521906 was filed for this purpose. There's still a server-side component that will need to be fixed to actually gather the data. You may not think it's required for us to protect users from themselves, but when a problem becomes this widespread (probably as a result of major blogs and news sites telling users to use this pref) then taking action seems like the right solution.

Comment 49

[Dave Townsend [:mossop]]

(In reply to comment #47)
> I do spend some times on those forums, although admittedly not as much as
> others probably do.  I still question whether it is this setting which causes
> the problem, or PEBKAC issues...  I don't particularly believe that the devteam
> ought to feel itself responsible to prevent uneducated users from poking
> themselves in the eye with a setting they don't understand.

It is our responsibility to help users to not shoot their feet off.

> either way, i think the bigger annoyance here was that it all of a sudden
> changed without warning.  I might suggest to add a line to the kb article on
> extensions.checkCompatibility that the behavior has changed and an explanation
> of how to use it.  as it was, the only way i found out about this was lodging a
> separate bug because my search of bugzilla didn't turn this bug up.  props,
> however, to the user that marked my bug as a dupe of this.

I blogged about the change a few days in advance, it would have appeared on planet.mozilla.org. It was also mentioned in the nightly build threads on the forums. I will try to remember updating the KB in future, is there anywhere else an announcement could have helped?

Comment 50

[Barry Marshall]

Maybe a warning as well on http://www.mozilla.org/projects/minefield/ ?

Comment 51

[cris]

so exactly what should I set the string value to be? 

I m using Nomaroka nightly build 3.6b2pre

should I use extensions.checkCompatibility.3.6b2pre ?

Comment 52

[Dave Townsend [:mossop]]

(In reply to comment #51)
> so exactly what should I set the string value to be? 
> 
> I m using Nomaroka nightly build 3.6b2pre
> 
> should I use extensions.checkCompatibility.3.6b2pre ?

From comment 18, extensions.checkCompatibility.3.6b

Comment 53

[Tony Chung [:tchung]]

Verified fix on Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b3pre) Gecko/20091111 Namoroka/3.6b3pre
and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091111 Minefield/3.7a1pre

Comment 54

[Mahesh Asolkar]

Attachment: Screen shot of Shredder Add-ons screen

'extensions.checkCompatibility.3.7a' worked for me in Minefield.

But I can't seem to find the right perf name for Shredder (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091113 Shredder/3.0.1pre). I tried to append a variety of combinations '3.0.1pre', but none worked. I am currently using just 'extensions.checkCompatibility'. As the screen shot shows, there is a tip about Add-on compatibility checking being disabled. But it still says add-ons are not compatible. If I hit 'Enable' of any add-on, nothing happens.

Comment 55

[Dave Townsend [:mossop]]

(In reply to comment #54)
> Created an attachment (id=412258) [details]
> Screen shot of Shredder Add-ons screen
> 
> 'extensions.checkCompatibility.3.7a' worked for me in Minefield.
> 
> But I can't seem to find the right perf name for Shredder (Mozilla/5.0 (X11; U;
> Linux i686; en-US; rv:1.9.1.5) Gecko/20091113 Shredder/3.0.1pre). I tried to
> append a variety of combinations '3.0.1pre', but none worked. I am currently
> using just 'extensions.checkCompatibility'. As the screen shot shows, there is
> a tip about Add-on compatibility checking being disabled. But it still says
> add-ons are not compatible. If I hit 'Enable' of any add-on, nothing happens.

Your version of Shredder is on the 1.9.1 branch and so unaffected by this change.

Comment 56

[Veritas]

it is still just extensions.checkCompatibility on that branch

Comment 58

[Nickolay_Ponomarev]

> is there anywhere else an announcement could have helped?
Perhaps also on https://developer.mozilla.org/en/Firefox_3.6_for_developers -- it would at least reach the developers (c.f. bug 529795).

Comment 59

[Veritas]

im not sure if this is a separate bug, but this implementation no longer prevents extension compatibility checks on install, it only allows the running of extensions previously installed.

if i try to install a new extension that "isn't compatible" i now have to modify the install.rdf, which is an utter waste of time.

Comment 60

[Dave Townsend [:mossop]]

(In reply to comment #59)
> im not sure if this is a separate bug, but this implementation no longer
> prevents extension compatibility checks on install, it only allows the running
> of extensions previously installed.

Please file that as a separate bug.

Comment 61

[Veritas]

even though it is a regression that cropped up because of this bug?

Comment 62

[Dave Townsend [:mossop]]

(In reply to comment #61)
> even though it is a regression that cropped up because of this bug?

Yes

Comment 63

[Rebecca Menessec]

This seems to have completely broken search engine installs from Mycroft.  I have these booleans set to false:

extensions.checkCompatibility
extensions.checkCompatibility.1.9.2b
extensions.checkCompatibility.1.9.2b6pre
extensions.checkCompatibility.3.5
extensions.checkCompatibility.3.6b

...and I still get a pop-up telling me that any search engine I attempt to install is not compatible with Namoroka, and can't be installed.  It's not even clear whether the source of the pop-up is Namoroka, or Mycroft.  I have UA Switcher installed, and I see that switching to 3.5.6 strings (including JS responses) no longer affects about:, so I assume the .3.5 boolean is gratuitous.

However, about: doesn't contain any strings including "3.6"; only the Gecko/platform/xulrunner rev, so I'm not clear on whether Namoroka even *has* a version to compare against a extensions.checkCompatibility.*

For reference, the only thing on the page that's not part of the generated graphic and contains version info:

"Build identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.6) Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.5.6"

...(I'm using debs from the Ubuntu Mozilla Daily Build Team.)  Am I right?  Do nightly builds no longer have a "version" to compare against this boolean?  Should they be looking for "extensions.checkCompatibility.nightly"?

Comment 64

[Dave Townsend [:mossop]]

(In reply to comment #63)
> This seems to have completely broken search engine installs from Mycroft.  I
> have these booleans set to false:

*SNIP*

> "Build identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.6)
> Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.5.6"

This bug never landed on the 1.9.1 branch so it cannot be this.

Comment 65

[Rebecca Menessec]

(In reply to comment #64)
> (In reply to comment #63)
> > This seems to have completely broken search engine installs from Mycroft.  I
> > have these booleans set to false:
> 
> *SNIP*
> 
> > "Build identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.6)
> > Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.5.6"
> 
> This bug never landed on the 1.9.1 branch so it cannot be this.

Sorry, bad string.  Switch UA doesn't affect the main icon and name/version (Shiretoko icon and merely "version 1.9.2" in this case), but it does affect the build string.  It's properly:

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2pre) Gecko/20100106 Ubuntu/9.10 (karmic)

So, now that we've established I'm using Namoroka 3.6 (3.6~hg20100106r33490+nobinonly-0ubuntu1~umd1~karmic) and Gecko 1.9.2, and that this breaks lots of strings that would normally have a proper product name and version... ?

Comment 66

[Dave Townsend [:mossop]]

(In reply to comment #65)
> (In reply to comment #64)
> > (In reply to comment #63)
> > > This seems to have completely broken search engine installs from Mycroft.  I
> > > have these booleans set to false:
> > 
> > *SNIP*
> > 
> > > "Build identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.6)
> > > Gecko/20091215 Ubuntu/9.10 (karmic) Firefox/3.5.6"
> > 
> > This bug never landed on the 1.9.1 branch so it cannot be this.
> 
> Sorry, bad string.  Switch UA doesn't affect the main icon and name/version
> (Shiretoko icon and merely "version 1.9.2" in this case), but it does affect
> the build string.  It's properly:
> 
> Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2pre) Gecko/20100106
> Ubuntu/9.10 (karmic)

Please file a neg bug for your issue so we can track down what is going on without cluttering up this closed bug. I strongly suspect you are seeing a problem related to something else, this patch shouldn't affect search engines or anything else really.

Comment 67

[Jean-Louis Monteverde]

Checked and applied comment18 (https://bugzilla.mozilla.org/show_bug.cgi?id=521905#c18)
Having just updated to rel. 3.6, i put "extensions.checkCompatibility.3.6" also kept the "extensions.checkCompatibility". 
But doesn't seem to work, having still "not compatible":
- Adblock Plus
- Answers
- Customize Google
- Deutches Worterbuch
- Dictionnaire HunSpell en Français
- Easy Job Application
- Firefox Synchronisation Extension
- Firefox Universal Uploader (fireuploader)
- Gmail Space
- Gmail Manager
- Google Notebook
- IE Tab
- Live IP
- Linkedin
- myTimeZone (ebay)
...
and half a dozen more.

They all worked in previous "releases", that is 3.5.x, excep the Nokia PC SUite extension (PC Sync 2  Synchronisation Extension).

I just hope, i'm doing something wrong since the thread indicates clearly that only 3.6 should be placed at the end of the string.

Comment 68

[Rebecca Menessec]

(In reply to comment #67)
> Checked and applied comment18
> (https://bugzilla.mozilla.org/show_bug.cgi?id=521905#c18)
> Having just updated to rel. 3.6, i put "extensions.checkCompatibility.3.6" also
> kept the "extensions.checkCompatibility". 
> But doesn't seem to work, having still "not compatible":
> - Adblock Plus
> - Answers
> - Customize Google
> - Deutches Worterbuch
> - Dictionnaire HunSpell en Français
> - Easy Job Application
> - Firefox Synchronisation Extension
> - Firefox Universal Uploader (fireuploader)
> - Gmail Space
> - Gmail Manager
> - Google Notebook
> - IE Tab
> - Live IP
> - Linkedin
> - myTimeZone (ebay)
> ...
> and half a dozen more.
> 
> They all worked in previous "releases", that is 3.5.x, excep the Nokia PC SUite
> extension (PC Sync 2  Synchronisation Extension).
> 
> I just hope, i'm doing something wrong since the thread indicates clearly that
> only 3.6 should be placed at the end of the string.

They don't *work*, or they're marked "incompatible"?  If they're only listed as incompatible, then nothing is wrong, and your extensions are operating.  (Unless they're also marked "disabled.")

If you don't like seeing extensions marked incompatible-- you still get the warning --right-click each extension and select "Make Compatible."  You'll have to do it again when the next 3.6.x rev is released.

Stylish ( https://addons.mozilla.org/en-US/firefox/addon/2108 ) and http://userstyles.org/styles/17151 will hide most of the visibility in the Extensions list, if you're really, absolutely sure you don't want any kind of warning.  (But the list entries will still be unnaturally large, because I didn't take the time to figure out how to reverse that.)

Comment 69

[Jean-Louis Monteverde]

@rebecca menessec, comment 68
I checked, i am now on a 3.6 italian setup, clean, had no beta installed before),
as per your reply, the exclamation mark add-ons work (including the Google Notes), so I guess that the discrepancies  I mentioned belonged to my setup.
Everything works fine. I still have to test the Nokia add-in.
Mny tks, good job!

Comment 70

[Veritas]

one outstanding problem.  this allows CURRENTLY installed extensions to operate, but installing new extensions still go through the check process and will fail.  please re-open.

Comment 71

[Dave Townsend [:mossop]]

(In reply to comment #70)
> one outstanding problem.  this allows CURRENTLY installed extensions to
> operate, but installing new extensions still go through the check process and
> will fail.  please re-open.

That should not be the case except as noted in comment 30. Please file a new bug report if you are seeing something else.