Closed Bug 706794 Opened 13 years ago Closed 13 years ago

Add extensions.strictCompatibility pref to Thunderbird to make addons compatible-by-default

Categories

(Thunderbird :: General, defect)

defect
Not set
normal

Tracking

(thunderbird10+ fixed)

RESOLVED FIXED
Thunderbird 11.0
Tracking Status
thunderbird10 + fixed

People

(Reporter: standard8, Assigned: standard8)

References

Details

Attachments

(3 files)

+++ This bug was initially created as a clone of Bug #698653 +++

Firefox have done this on trunk builds, and I think we should do the same to help testing and get our confidence up.

We should also add the pref on aurora but set to disable add-ons by default, so we have the pref there should it need to be flipped, or testers want to flip it.
Attached patch The fixSplinter Review
Mainly looking for an rs here. I tested with an extension that is out of date wrt trunk, and it the add-on manager did the expected with this pref.
Attachment #578264 - Flags: review?(bwinton)
Attached patch Aurora fixSplinter Review
For now, keep strict compatibility turned on on earlybird.
Attachment #578268 - Flags: review?(bwinton)
Comment on attachment 578268 [details] [diff] [review]
Aurora fix

Review of attachment 578268 [details] [diff] [review]:
-----------------------------------------------------------------

So…  Why do we want strict compatibility in Aurora?  Just cause that's what we currently do, and we don't want to change that behaviour until we've done some more testing?

(r=me with that question answered.)
Attachment #578268 - Flags: review?(bwinton) → review+
(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #3)
> Comment on attachment 578268 [details] [diff] [review] [diff] [details] [review]
> Aurora fix
> 
> Review of attachment 578268 [details] [diff] [review] [diff] [details] [review]:
> -----------------------------------------------------------------
> 
> So…  Why do we want strict compatibility in Aurora?  Just cause that's what
> we currently do, and we don't want to change that behaviour until we've done
> some more testing?

That's what FF currently does. I believe they don't want it there just yet until they've done more testing.
Comment on attachment 578264 [details] [diff] [review]
The fix

Review of attachment 578264 [details] [diff] [review]:
-----------------------------------------------------------------

WFM!
Attachment #578264 - Flags: review?(bwinton) → review+
Checked in: http://hg.mozilla.org/comm-central/rev/e946196ad328
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 11.0
Attachment #578268 - Flags: approval-comm-aurora+
We now need to land setting the pref to false on beta, so cancelling the fixed flag so we can check that.
(In reply to Mark Banner (:standard8) from comment #8)
> We now need to land setting the pref to false on beta, so cancelling the
> fixed flag so we can check that.

My QA checks caught this bug [x.ref https://wiki.mozilla.org/Releases/SeaMonkey2.7#Bug_Queries], out of curiosity, why are we backout out the pref? (what did I miss along the way?)
(In reply to Justin Wood (:Callek) from comment #9)
> (In reply to Mark Banner (:standard8) from comment #8)
> > We now need to land setting the pref to false on beta, so cancelling the
> > fixed flag so we can check that.
> 
> My QA checks caught this bug [x.ref
> https://wiki.mozilla.org/Releases/SeaMonkey2.7#Bug_Queries], out of
> curiosity, why are we backout out the pref? (what did I miss along the way?)

I didn't say anything about backing out. I said we need to set the pref to false - if you look at what was landed, the pref is currently true.
(In reply to Mark Banner (:standard8) from comment #10)
> (In reply to Justin Wood (:Callek) from comment #9)
> > (In reply to Mark Banner (:standard8) from comment #8)
> > > We now need to land setting the pref to false on beta, so cancelling the
> > > fixed flag so we can check that.
> > 
> > My QA checks caught this bug [x.ref
> > https://wiki.mozilla.org/Releases/SeaMonkey2.7#Bug_Queries], out of
> > curiosity, why are we backout out the pref? (what did I miss along the way?)
> 
> I didn't say anything about backing out. I said we need to set the pref to
> false - if you look at what was landed, the pref is currently true.

Ooooo right, the boolean logic in my head flipped when I commented here. Thanks
Attached patch The fixSplinter Review
Firefox enabled this on aurora, which is now beta after the merge, hence we should do this on beta as its better for extensions.
Attachment #586212 - Flags: review?(dbienvenu)
Attachment #586212 - Flags: review?(dbienvenu) → review+
You need to log in before you can comment on or make changes to this bug.