698653 - Flip extensions.strictCompatibility pref in Firefox to make addons compatible-by-default

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Bug 693901 added the pref, but there's a bunch of other stuff that should happen first (dependents of bug 692664).

Comment 1

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: Patch v1

Currently still missing bug 693906, but all the other precautions have landed (or are waiting to be merged). So I'm calling this "safe" in the sense that any addon that is likely to truly incompatible should be marked as such. And if not, then it's either a new bug or an exception that can be added to the AMO database (which is currently void of useful data).

Also missing bug 527141, but I don't think that should hold up using/testing everything else.

Comment 2

[solcroft]

I'm testing this pref by flipping it to "false" in the 11/15 Nightly, and while it seems to work fine for extensions (they no longer show up in the AOM with the "not compatible" warning) it apparently fails for themes. Is this by design or a bug?

Comment 3

[Dave Townsend [:mossop]]

(In reply to solcroft from comment #2)
> I'm testing this pref by flipping it to "false" in the 11/15 Nightly, and
> while it seems to work fine for extensions (they no longer show up in the
> AOM with the "not compatible" warning) it apparently fails for themes. Is
> this by design or a bug?

By design, themes are always in strict compatibility mode

Comment 4

[solcroft]

(In reply to Dave Townsend (:Mossop) from comment #3)
> By design, themes are always in strict compatibility mode

In my experience, most themes have worked remarkably well in unsupported channels since Firefox 5. Perhaps another pref specifically for themes could be coded in? It would make testing future release channels a lot more pleasant, and potentially avoid backlash/disappointment from users when they find out that Mozilla's solution to deal with incompatible add-ons was apparently only a half-baked effort.

Comment 5

[Dave Townsend [:mossop]]

(In reply to Blair McBride (:Unfocused) from comment #1)
> Created attachment 574570 [details] [diff] [review] [diff] [details] [review]
> Patch v1
> 
> Currently still missing bug 693906, but all the other precautions have
> landed (or are waiting to be merged). So I'm calling this "safe" in the
> sense that any addon that is likely to truly incompatible should be marked
> as such. And if not, then it's either a new bug or an exception that can be
> added to the AMO database (which is currently void of useful data).

I'm a little concerned at the risk without being able to block bad add-ons at this point, I don't think we should push this down to aurora until we have that but for nightly testing it seems ok.

Comment 6

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Dave Townsend (:Mossop) from comment #5)
> I'm a little concerned at the risk without being able to block bad add-ons
> at this point, I don't think we should push this down to aurora until we
> have that but for nightly testing it seems ok.

Agreed, and that's my plan. Once we get to that stage, the product team will make the call whether to enable it on Aurora (with our input, of course).

https://hg.mozilla.org/integration/fx-team/rev/6f2b6f7b3354

Comment 7

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to solcroft from comment #4)
> In my experience, most themes have worked remarkably well in unsupported
> channels since Firefox 5. 

That's anecdotal evidence, however. Because of the way themes currently work, they are more susceptible to breakage due to changes in the application. Given that each new application version will involve some change in the UI, themes that haven't been updated are very likely to have *something* broken. Which is fine for knowledgeable testers, but I don't think it's something that the average user should deal with.

If you'd like some wider discussion on this, a post to the dev-apps-firefox newsgroup would be useful.

Comment 8

[solcroft]

(In reply to Blair McBride (:Unfocused) from comment #7)
> If you'd like some wider discussion on this, a post to the dev-apps-firefox
> newsgroup would be useful.

I've made a post at https://groups.google.com/forum/#!topic/mozilla.dev.apps.firefox/HDFiu3mJ3Ws

Comment 9

[Blair McBride [:Unfocused] (UNAVAILABLE)]

https://hg.mozilla.org/mozilla-central/rev/6f2b6f7b3354

Comment 10

[Bruce A. Wittmeier]

(In reply to solcroft from comment #2)
> I'm testing this pref by flipping it to "false" in the 11/15 Nightly, and
> while it seems to work fine for extensions (they no longer show up in the
> AOM with the "not compatible" warning) it apparently fails for themes. Is
> this by design or a bug?
This is notworking as described for me - Nightly 11.0a1 11192011 Same results regardless of extensions.strictCompatibility true or false.

[url=http://i.imgur.com/5q2Rvs.jpg][img]http://i.imgur.com/5q2Rv.jpg[/img][/url]

Comment 11

[Bruce A. Wittmeier]

Sorry about the link to the image:

http://i.imgur.com/5q2Rv.jpg

Comment 12

[Bruce A. Wittmeier]

I stand corrected.  If you had the setting "extensions.checkCompatibility.nightly" set false, you must remove this setting for the "extensions.strictCompatibility" set false to take effect.  Sorry.

Comment 13

[Brian King [:kinger]]

(In reply to Bruce A. Wittmeier from comment #12)
> I stand corrected.  If you had the setting
> "extensions.checkCompatibility.nightly" set false, you must remove this
> setting for the "extensions.strictCompatibility" set false to take effect. 
> Sorry.

This therefore sounds to me like there will be a conflict between this feature and the Add-on Compatibility Reporter.

Comment 14

[Bruce A. Wittmeier]

Brian,

I believe your observations are correct.

There is a possible issue as when the Addon Compatibility Reporter is enabled, you cannot remove or change extensions.checkCompatibility flag from false.

With extensions.strictCompatibility is false and extensions.checkCompatibility.nightly true or removed, Reporter disabled the warning(s) do not appear.

Apparently, the extensions.checkCompatibility.nightly;false is inserted and set to false when the Addon Compatibility Reporter is installed or enabled.

Comment 15

[Brian King [:kinger]]

This is unfortunate. I'm not sure if the solution is a) a technical one b) make ACR incompatible with nightlies, though I suspect a fair chunk of users already have it installed there, or c) add a large warning to the ACR install page about the dangers + a workaround.

Note ACR is being rewritten very soon and it will not be setting any prefs, just allowing the users to report misbehaving add-ons. But until that happens we'll need a strategy to handle this clash in nightlies.

Comment 16

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 574570 [details] [diff] [review]
Patch v1

I should landing the remaining patches on Aurora today (assuming they get approval). And no regressions on Nightly have been found yet. Also, the related changes just went live on AMO's production site. So I think it's time to enable this on Aurora.

My recommendation is for me to enable this on Monday (NZ time), and keep a close eye on any reports of things misbehaving. We should see any regressions within a week - if something comes up, we can very easily disable it again (before the merge to Beta) to revert back to the old behaviour on Fx10.

Comment 17

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Brian King (Briks) [:kinger] from comment #15)
> This is unfortunate. I'm not sure if the solution is a) a technical one b)
> make ACR incompatible with nightlies, though I suspect a fair chunk of users
> already have it installed there, or c) add a large warning to the ACR
> install page about the dangers + a workaround.
> 
> Note ACR is being rewritten very soon and it will not be setting any prefs,
> just allowing the users to report misbehaving add-ons. But until that
> happens we'll need a strategy to handle this clash in nightlies.

This has been addressed in bug 708931, which made ACR re-enable compatibility checks whenever it sees compatible-by-default is supported and enabled. v1.0.1 has been released with that fix.

Also, a compatibility override was added to AMO's database for versions of ACR upto v1.0. That will make previous versions of ACR incompatible whenever compatible-by-default is enabled; however it has no effect when ACR is already installed and enabled (since it disables such checks), thus the need for v1.0.1. But it does mean that user's can't install old versions, and if they have an old version disabled they can't enable it.

(It was also our first real-world non-synthetic test of compatibility overrides - works well!)

Comment 18

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 574570 [details] [diff] [review]
Patch v1

Approving for Aurora as per the release drivers decision on 2011-12-08.

Comment 19

[Blair McBride [:Unfocused] (UNAVAILABLE)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/3605cb8cb3db

Comment 20

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a2) Gecko/20111215 Firefox/10.0a2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0a1) Gecko/20111215 Firefox/11.0a1

The pref is now set to false by default, both in Aurora (F10) and in Nightly (F11).