If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Software Update should do an Extension Update check before showing prompt UI

RESOLVED FIXED in Future

Status

()

Toolkit
Application Update
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: Ben Goodger (use ben at mozilla dot org for email), Unassigned)

Tracking

unspecified
Future
Points:
---
Bug Flags:
blocking1.8rc2 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 1 obsolete attachment)

If the user has some extensions installed, then if any of them will be made
incompatible by a new software update, we show the dialog asking them if they
want to upgrade or not. 

Given that we can general assume that when the user is forced to make a decision
they will almost always make the wrong one (not update to the latest security
fixes), having a situation where no UI is shown and the app is background
updated is the best one. 

To avoid incompatibilities while not showing the UI more than necessary, the
update check process should be modified like so:

- when an update is found that will make some extensions incompatible:

 1) The Update Service should kick off an Addon Update check and have its own
    object implementing nsIAddonUpdateCheckListener to collect the results.
 2) After all VersionInfo updates have been applied, if there are any addons
    that are a) not compatible with the new release and b) do not have newer,
    compatible versions available for download THEN we show the UI, otherwise
    we silently update - the user will be asked to update their extensions using
    the mismatch UI on the first startup after upgrading.
Status: NEW → ASSIGNED
Flags: blocking1.8b4?
Flags: blocking1.8b4? → blocking1.8b4+
Whiteboard: ETA: 8/5

Updated

12 years ago
Blocks: 290390
Created attachment 191401 [details] [diff] [review]
work in progress

This does not apply, since it's in the same tree as some of my other changes,
but gives an indication as to the extent of the changes.
Created attachment 191414 [details] [diff] [review]
patch
Attachment #191401 - Attachment is obsolete: true
Attachment #191414 - Flags: review?(darin)

Comment 3

12 years ago
Comment on attachment 191414 [details] [diff] [review]
patch

>Index: toolkit/mozapps/update/src/nsUpdateService.js.in

>-
>+  

whitespace nit


>+#ifdef MOZ_XUL_APP

you could also change this to a run-time check, like if haveEM,
but this is fine too.


>+      var mode = getPref("getIntPref", PREF_APP_UPDATE_INCOMPATIBLE_MODE, 0);
>+      if ((mode == 0 && this._addons.length) || !isCompatible(update))
>+        showPrompt(update);

it might be nice to define constants for the various values that
this pref may have.


>Index: browser/app/profile/firefox.js

thunderbird needs similar pref loving.


r=darin
Attachment #191414 - Flags: review?(darin) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
failing in all cases except background update version update (see bug 314258)

testcase on the way
Status: RESOLVED → REOPENED
Flags: blocking1.8rc2?
Resolution: FIXED → ---
Created attachment 201702 [details]
testcase

testcase isntructions
Created attachment 201703 [details]
testcase xpi

extension for testcase
Created attachment 201704 [details]
testcase update.xml

app update xml file for testcase
Created attachment 201705 [details]
testcase versioncheck.xml

versioncheck xml file for testcase

Updated

12 years ago
Flags: blocking1.8rc2? → blocking1.8rc2+

Updated

12 years ago
Assignee: bugs → beng
Status: REOPENED → NEW

Comment 9

12 years ago
Per Discussion with Ben/Darin/Bug Triage team today the fix for this is rather involved and has the risk of regressing software update in general.   Since we are recommending that all extension developers use the 1.5.0.* syntax this should only really show up when we do 1.5->2.0 upgrades and we can address then if there is need.
Flags: blocking1.8rc2-
Flags: blocking1.8rc2+
Flags: blocking1.8b5+
Whiteboard: ETA: 8/5
Target Milestone: --- → Future

Comment 10

11 years ago
I do not not if this problem belongs to this bug or if it is a new bug.
After updating to trunk 2006062607 i got this update check window. I have two problems with it:
- There is no CANCEL/LATER button
- The update manager seems not to be able to use authentification proxies. I have one (corporate proxy) and the download fails with error -228 (or -208). (can not remember exactly)

After that there is no active button anymore on the dialog. You have to use the window close button to continue. If you try the update later in the addon manager it works fine.
Reassigning to nobody since clearly Ben won't be working on this any time soon.
Assignee: beng → nobody
Also, what exactly needs to be done here still? Software Update most definitely checks for updates for incompatible extensions these days. Can this be resolved WORKSFORME?
Closing this as fixed, the patch landed on 2005-08-03
Status: NEW → RESOLVED
Last Resolved: 12 years ago10 years ago
Resolution: --- → FIXED
(Assignee)

Updated

9 years ago
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.