Closed Bug 1269133 Opened 3 years ago Closed 3 years ago
Remove add-on compatibility check from application update (app
(From Bug 1262880 comment #0) > According to telemetry at most 0.5% of background update checks have > incompatible add-ons. > The add-ons manager code is always called when there is an app version > change for an update. > There have been add-ons that override the add-ons manager code and break > application update even though both the add-ons manager and application > update have been coded to prevent this in most circumstances. > There have been add-ons that are essentially abandoned which will require > the user to opt-in to getting an application update instead of updating > silently. For example, this happened with google toolbar years ago. > Supporting the add-on compatibility check requires UI and code that is > complex and it is the one piece that will prevent us from never showing UI > to update if we choose to require application updates. > Since the add-on compatibility check requires a user to opt-in to the update > when an add-on is incompatible with the new version it is another step in > the update process where the user might not update and hence not get > security fixes as well as increase the number of users on older versions > (e.g. update orphaning).
Remove app.update.mode from browser-prefs.js and remove the UI from suite/common/pref/smart-update since this was removed from toolkit in Bug 1262880
(In reply to Philip Chee from comment #0) > Remove app.update.mode from browser-prefs.js and remove the UI from > suite/common/pref/smart-update since this was removed from toolkit in Bug > 1262880 Also increase app.update.promptWaitTime" to 691200 (184 hours)
I'll have a look.
Assignee: nobody → rsx11m.pub
Status: NEW → ASSIGNED
Hmm, I would mark status-seamonkey2.45 as "unaffected" but that flag somehow got lost? I see status-seamonkey2.44 and status-seamonkey2.46, but nothing in-between.
This also removes app.update.incompatible.mode, which is now redundant and no longer used anywhere. Note that I've adjusted the spacing of the appModeAutoEnabled a bit to match the horizontal relation between the "Automatically check" and "Automatically download" boxes between the "Add-ons" and "SeaMonkey" groups. Turns out that <vbox class="indent"> gives a slightly larger space than the corresponding <checkbox class="indent">, thus now it's consistent between the two groups. Help content for that prefpane has been adjusted accordingly. (In reply to rsx11m from comment #4) > Hmm, I would mark status-seamonkey2.45 as "unaffected" but that flag somehow got lost? That's bug 1268980, apparently something was copy-pasted in a wrong way during the last merge.
(In reply to Philip Chee from comment #1) > Also increase app.update.promptWaitTime" to 691200 (184 hours) Actually, that's 192 hours (or 8 days). It's still 43200 for the Firefox nightly builds, by the way. Thus, should this be wrapped into an #ifdef on RELEASE to match the intent of bug 1268340?
Yeah, this seems to be better. Bug release users after 8 days, nightly users after 12 hours when an update is available.
Comment on attachment 8748462 [details] [diff] [review] Port bug 1268340 more literally r/a=me
Attachment #8748462 - Flags: review?(iann_bugzilla) → review+
Thanks, pushed as http://hg.mozilla.org/comm-central/rev/04072c577407
You need to log in before you can comment on or make changes to this bug.