391598 - make upgrade/update process smoother and avoid confusing/modal dialogs

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect, P1)

Description

[Mike Connor [:mconnor]]

Bug 334767 is a part of this, but that's a long ranty bug and only part of the solution I'm proposing.

I believe the right UX here is to not aggressively prompt and interrupt the current user action, and if no action is taken, apply the update on next startup.  At the same time, we want to be mindful of getting users protected as soon as possible, so we need to a) provide an unobtrusive indicator that users can click on for details and to apply the update, and b) prompt after a predetermined period of time with a better designed dialog, using nsIIdleService to be sure that the user isn't interacting with the browser at the time.

Proposed flow:

1. Update is downloaded

2. When ready, a sticky nsIAlertService call is made.  This should be fairly unobtrusive, but clearly visible to users and compelling to click on.

3a. Clicking the notification brings up the cleaned up update dialog (without the misleading Later option).

3b. If the user doesn't act on the sticky notification within X hours (I'd propose 2-4), add an nsIIdleService timer to find a time when the user is not interacting with the app, and show the dialog at that time.  This means we still prompting the user so they don't browse for days insecurely without notificing, but better design and user idleness makes it unlikely that we'll have the same "I was typing in a web form and kaboom" problems we have with the current interaction.

3c. If the user shuts down the app in less than X hours, they'll get the update without further prompting on next startup.

Thoughts?

Comment 1

[Daniel Veditz [:dveditz]]

By "sticky" you mean the alert will just sit there in the corner until the user does something with it, right? I think that's a good balance between an evil in-your-face modal interruption and a too-subtle chrome indication. I personally would like "X" in 3b to be on the long side, or even have a disable pref.

Speaking of prefs, how does this interact with the "ask me first" update pref? I'd imagine you can use the exact same sticky alert, and if the user clicks on it bring up something like the current "ask me" dialog rather than the "apply now" dialog.

The update must not happen directly upon clicking in the alert, it should be worded more like "click here for details" so the user can get to the release notes from the dialog and possibly cancel out (mconnor says we can't have two links in the alert itself, unfortunately).

Comment 2

[(not reading, please use [e-mail] instead)]

see also related bug #351471: wait until the user is idle before showing the software update window

Comment 3

[Dão Gottwald [:dao]]

(In reply to comment #0)
> 3c. If the user shuts down the app in less than X hours, they'll get the update
> without further prompting on next startup.

Unless there'll be incompatible add-ons and "Warn me if this will disable any of my add-ons" is checked, which it is by default.

Comment 4

[Mike Connor [:mconnor]]

So, what I said in comment 0, but drop the sticky part of the notification and make X 12-24 hours.

We don't want to be longer than 12-24 hours, since that will mean users are left exposed for longer than necessary, and one of our key goals with software update is to keep users updated and as secure as possible.  We actually talk speed of update up a lot publicly, and I don't want to make it too obtrusive.  The notification should be trivial (it was a small patch to do the same for Add-on updates, so we should be able to do this without a lot of pain), and we already have the idle timer piece hooked up.

Comment 5

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

I think all of mconnor's comments are for the default case (which is to automatically download and to warn if there's add-on incompatibility).

FWIW, I'd rather have the nsIAlertService called in non-sticky mode, as otherwise it's basically the same thing (there's a bit of UI that stays there until the user attends to it). It should just say "An update is available for Firefox" and clicking on it should do the same as clicking on "Help -> Apply Downloaded Update..."

I'd also suggest that X be 48 hours, since as soon as we throw up that dialog, we're basically asking for the user to attend to it.

Comment 6

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

Heh, comment collision. Looks like we agree on everything except for the timeout. I guess I can live with 24hrs.

Comment 7

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

Relevant "see also" bugs ...
- don't pop modal dialog within X hours is basically bug 407780
- don't pop modal dialog when app is in background is bug 407536
- similar request for 1.8.1 branch is bug 397409

Comment 9

[Mike Connor [:mconnor]]

-> Dao, who I think has both cycles and enough knowledge of this code to take this from Seth

Comment 10

[Dão Gottwald [:dao]]

Attachment: patch v1 (checked in)

Relevant prefs for UI review:

-// Interval: Time before prompting the user to restart to install the latest
-//           download (in seconds) default=30 minutes
-pref("app.update.nagTimer.restart", 1800);
+// Interval: Time before prompting the user again to restart to install the
+//           latest download (in seconds) default=1 day
+pref("app.update.nagTimer.restart", 86400);

+// Give the user x seconds to react before showing the big UI. default=12 hrs
+pref("app.update.promptWaitTime", 43200);

Note that "the big UI" is shown using the existing idle timer (60 seconds).

Relevant strings for UI review to be used in the small notification alert:

+updateAvailable_minor.title=%S available
+updateAvailable_minor.text=Download & Install…
+updateAvailable_major.title=%S available
+updateAvailable_major.text=Get the new version…
+updateDownloaded_minor.title=%S available
+updateDownloaded_minor.text=Apply Downloaded Update…
+updateDownloaded_major.title=%S available
+updateDownloaded_major.text=Install the new version…

Comment 11

[Dão Gottwald [:dao]]

(In reply to comment #0)
> 3a. Clicking the notification brings up the cleaned up update dialog (without
> the misleading Later option).

Should there be the standard Cancel button instead of Later, or no such button at all?

Comment 12

[Grey Nicholson (they/them)]

In Gnome it should probably say “Close” rather than “Cancel” since it simply closes the dialogue and doesn't revert any changes made in that dialogue (unlike, for example, cancelling changing a setting).

(Also, the dialogue that pops up when you click Cancel, saying “YES I WILL GO AWAY AND LEAVE YOU ALONE NOW! [OK]” should die, but you knew that already.)

Comment 13

[(not reading, please use [e-mail] instead)]

sorry for the delay and thanks for working on this, dao.

a few comments / questions:

1)

+      var imageUrl = "";

I think we want to specify the image url, maybe something like chrome://branding/content/icon48.png (but I'm not sure if that will work for sunbird and thunderbird)

In addition to the text, the image might help indicate which application the alert is associated with, iif I'm running both firefox and thunderbird.

2)

-  showUpdateDownloaded: function(update, whenIdle) {
-    if (this._enabled) {
-      if (whenIdle)
-        this._showUIWhenIdle(null, URI_UPDATE_PROMPT_DIALOG, null,
-                             "Update:Wizard", "finishedBackground", update);
-      else
-        this._showUI(null, URI_UPDATE_PROMPT_DIALOG, null,
-                     "Update:Wizard", "finishedBackground", update);
+  showUpdateDownloaded: function(update, background) {
+    if (background) {
+      if (!this._enabled)
+        return;
+      var bundle = this._updateBundle;
+      var stringsPrefix = "updateDownloaded_" + update.type + ".";
+      var title = bundle.formatStringFromName(stringsPrefix + "title", [update.name], 1);
+      var text = bundle.GetStringFromName(stringsPrefix + "text");
+      var imageUrl = "";
+      this._showUnobtrusiveUI(null, URI_UPDATE_PROMPT_DIALOG, null,
+                              "Update:Wizard", "finishedBackground", update,
+                              title, text, imageUrl);
+    } else {
+      this._showUI(null, URI_UPDATE_PROMPT_DIALOG, null,

should the "if (!this._enabled) return;" be moved outside the "if (background)"?

3)

+    try {
+      var notifier = Components.classes["@mozilla.org/alerts-service;1"]
+                               .getService(Components.interfaces.nsIAlertsService);
+      notifier.showAlertNotification(imageUrl, title, text, true, "", observer);
+    }
+    catch (e) {
+      // Failed to retrieve alerts service, platform unsupported
+      this._showUIWhenIdle(parent, uri, features, name, page, update);
+      return;
+    }

on mac, what happens if I don't have growl installed?  

I'm worried that showAlertNotification will not throw.

4)
 
+  get _updateBundle() {
+    return Components.classes["@mozilla.org/intl/stringbundle;1"]
+                     .getService(Components.interfaces.nsIStringBundleService)
+                     .createBundle(URI_UPDATES_PROPERTIES);
+  },

Optionally, you could use the memoization trick here (see "get _bundle()" in mozilla/browser/components/places/content/utils.js).

Comment 14

[Dão Gottwald [:dao]]

(In reply to comment #13)
> 1)
> I think we want to specify the image url, maybe something like
> chrome://branding/content/icon48.png (but I'm not sure if that will work for
> sunbird and thunderbird)
> 
> In addition to the text, the image might help indicate which application the
> alert is associated with, iif I'm running both firefox and thunderbird.

Sure, an icon would be nice. Thunderbird seems to have icon64.png but not icon48.png.

> 2)
> should the "if (!this._enabled) return;" be moved outside the "if
> (background)"?

_enabled is !app.update.silent, which I think makes only sense for background calls, i.e. not "Help > Apply update".

> 3)
> on mac, what happens if I don't have growl installed?  
> 
> I'm worried that showAlertNotification will not throw.

http://developer.mozilla.org/en/docs/nsIAlertsService#Exceptions_thrown says it will throw.

> 4)
> 
> +  get _updateBundle() {
> +    return Components.classes["@mozilla.org/intl/stringbundle;1"]
> +                     .getService(Components.interfaces.nsIStringBundleService)
> +                     .createBundle(URI_UPDATES_PROPERTIES);
> +  },
> 
> Optionally, you could use the memoization trick here (see "get _bundle()" in
> mozilla/browser/components/places/content/utils.js).

In case there are many UpdatePrompt instances (it's not a singleton), the memorization trick wouldn't be a win. And within a single instance, we shouldn't be calling that getter too often (usually only once).

Comment 15

[(not reading, please use [e-mail] instead)]

Comment on attachment 293383 [details] [diff] [review]
patch v1 (checked in)

r=sspitzer

thanks for answering all my questions and comments.

let's check with beltzner to see if he wants the image UI or not.

We should update the appropriate documentation on http://wiki.mozilla.org/Software_Update to reflect these changes

Comment 16

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

Dao/Seth,

Could I either get a quick description of what the attached patch does, or an update channel where I can test it out?

Comment 17

[Dão Gottwald [:dao]]

With the patch we'll call nsIAlertService (non-sticky) once an update is ready to install. Clicking it brings up the current update notification window. Otherwise we'll pop up the notification window automatically after 12 hours and at least one minute idle time so that we don't steal focus.

Unfortunately I don't know how to test this properly. I did it by hacking a nightly build.

Comment 18

[Nick Thomas [:nthomas] (UTC+12)]

Seth Spitzer set up a bunch of test cases in bug 357358. If you have a build (eg from the try server), then you can test a null-update like this:

1, in about:config, create a new string pref called app.update.url.override
2, set the value to https://bugzilla.mozilla.org/attachment.cgi?id=243412
3, wait for notification

Expect to see an offer for Firefox 2.5 (in the minor-update style), a near instantaneous download (only 54 bytes), and no change to Firefox after the restart (the update mar specifies no changes).

Hopefully Dão can suggest a way to tweak the 12 hours to something easily testable.

Comment 19

[Dão Gottwald [:dao]]

(In reply to comment #18)
> Seth Spitzer set up a bunch of test cases in bug 357358. If you have a build
> (eg from the try server), then you can test a null-update like this:
> 
> 1, in about:config, create a new string pref called app.update.url.override
> 2, set the value to https://bugzilla.mozilla.org/attachment.cgi?id=243412
> 3, wait for notification
> 
> Expect to see an offer for Firefox 2.5 (in the minor-update style), a near
> instantaneous download (only 54 bytes), and no change to Firefox after the
> restart (the update mar specifies no changes).

Thanks.

> Hopefully Dão can suggest a way to tweak the 12 hours to something easily
> testable.

Yeah, it's a pref (app.update.promptWaitTime). See comment 10.

Comment 20

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

Comment on attachment 293383 [details] [diff] [review]
patch v1 (checked in)

I think I'd prefer 24 hours over 12 for the timeout, but this is good enough for now and that's an easy follow up fix.

Looked fine on Windows, it'll be easier to test in nightlies, so let's put it there.

Comment 21

[Dão Gottwald [:dao]]

Note that "cleaned up update dialog (without the misleading Later option)" isn't yet done (comment 11).

Comment 22

[Reed Loden [:reed]]

File a separate bug on comment #11, I guess?

Checking in browser/app/profile/firefox.js;
/cvsroot/mozilla/browser/app/profile/firefox.js,v  <--  firefox.js
new revision: 1.250; previous revision: 1.249
done
Checking in browser/base/content/utilityOverlay.js;
/cvsroot/mozilla/browser/base/content/utilityOverlay.js,v  <--  utilityOverlay.js
new revision: 1.59; previous revision: 1.58
done
Checking in calendar/sunbird/base/content/applicationUtil.js;
/cvsroot/mozilla/calendar/sunbird/base/content/applicationUtil.js,v  <--  applicationUtil.js
new revision: 1.27; previous revision: 1.26
done
Checking in calendar/sunbird/app/profile/sunbird.js;
/cvsroot/mozilla/calendar/sunbird/app/profile/sunbird.js,v  <--  sunbird.js
new revision: 1.49; previous revision: 1.48
done
Checking in mail/app/profile/all-thunderbird.js;
/cvsroot/mozilla/mail/app/profile/all-thunderbird.js,v  <--  all-thunderbird.js
new revision: 1.104; previous revision: 1.103
done
Checking in mail/base/content/mailWindowOverlay.js;
/cvsroot/mozilla/mail/base/content/mailWindowOverlay.js,v  <--  mailWindowOverlay.js
new revision: 1.182; previous revision: 1.181
done
Checking in suite/browser/browser-prefs.js;
/cvsroot/mozilla/suite/browser/browser-prefs.js,v  <--  browser-prefs.js
new revision: 1.80; previous revision: 1.79
done
Checking in toolkit/locales/en-US/chrome/mozapps/update/updates.properties;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/update/updates.properties,v  <--  updates.properties
new revision: 1.36; previous revision: 1.35
done
Checking in toolkit/mozapps/update/content/updates.js;
/cvsroot/mozilla/toolkit/mozapps/update/content/updates.js,v  <--  updates.js
new revision: 1.79; previous revision: 1.78
done
Checking in toolkit/mozapps/update/public/nsIUpdateService.idl;
/cvsroot/mozilla/toolkit/mozapps/update/public/nsIUpdateService.idl,v  <--  nsIUpdateService.idl
new revision: 1.48; previous revision: 1.47
done
Checking in toolkit/mozapps/update/src/nsUpdateService.js.in;
/cvsroot/mozilla/toolkit/mozapps/update/src/nsUpdateService.js.in,v  <--  nsUpdateService.js.in
new revision: 1.146; previous revision: 1.145
done

Comment 23

[Dão Gottwald [:dao]]

(In reply to comment #22)
> File a separate bug on comment #11, I guess?

Oops, I missed that line.

Anyway, I think it should be handled here, because it's part of what was considered blocking‑firefox3+.

Comment 24

[Simon Paquet [:sipaq]]

Dão, we currently have a pretty strict cross-commit policy for all files in mozilla/calendar. 

To avoid confusion (especially with regards to the applicationUtils.js file) my question is, whether the change to that file can be duplicated on the MOZILLA_1_8_BRANCH?

Or would that lead to unfortunate consequences?

Lastly, we really appreciate that you performed this change tree-wide. But please CC at least one person from the Calendar team (I suggest our project lead Daniel Boelzle - [e-mail]) to keep us in the loop. Thanks.

Comment 25

[Dão Gottwald [:dao]]

(In reply to comment #24)
> To avoid confusion (especially with regards to the applicationUtils.js file) my
> question is, whether the change to that file can be duplicated on the
> MOZILLA_1_8_BRANCH?
> 
> Or would that lead to unfortunate consequences?

In applicationUtil.js, I've removed the argument that I added in bug 405078, so there shouldn't be a difference.
The prefs that exist on the 1.8 branch, i.e. app.update.nagTimer.restart, shouldn't be changed just to avoid confusion.

Comment 26

[Marek Stępień [:marcoos, inactive]]

Could you add localization notes to those strings in updates.properties? Trying to figure out what the %S in "%S available" stands for may not be trivial to localizers.

Comment 27

[Dão Gottwald [:dao]]

(In reply to comment #26)
Aren't the identifiers, updateAvailable~ and updateDownloaded~, descriptive enough? It's the name of the update (what else?). Just like in updateReadyToInstallHeader in the same file.

Comment 28

[Marek Stępień [:marcoos, inactive]]

So, to make things clear, it's like "Firefox 3.0.0.1 available", right?

Comment 29

[Axel Hecht [:Pike]]

Well, I can make up at least two, in particular "what the update server claimed this thing should be called" (which I suspect it is, right?) or something like
appname - version.

From reading other bugs (not sure which), this will in the end turn out to be a string localized on the server side, if the application in question actually offers that on their AUS?

I think a comment would be good, because any language with grammar should probably translate into something with "it's knees *way* bent" to deal with the stuff coming in.

Are the strings displayed in this context re-used in other contexts? Something like the "Downloading ..." in the help menu? That set should probably have comments cross referencing each other so that they're consistently awkwardly localized. In particular if you're talking about "application"- or "patch"-like things.

Comment 30

[Dão Gottwald [:dao]]

It's updateName from line 1. updateName is brandShortName plus the version.

Comment 31

[Reed Loden [:reed]]

(In reply to comment #28)
> So, to make things clear, it's like "Firefox 3.0.0.1 available", right?

Completely off-topic, but just so you know, the first update to Firefox 3 will be Firefox 3.0.1, not 3.0.0.1. We're dropping that extra octet. :)

Comment 32

[Nick Thomas [:nthomas] (UTC+12)]

I got a short-lived Growl notification for a nightly update with this change. Obviously it depends on my particular Growl settings ("Bubbles", 4s duration), but is this the expected behaviour ?

Comment 33

[Dão Gottwald [:dao]]

Yep.

Comment 35

[Axel Hecht [:Pike]]

Filed bug 412793 to add comments to update.properties at large, that file is just cryptic.

Comment 37

[Henrik Skupin [:whimboo][⌚️UTC+1]]

After some days of experience with the new "toast" update alert on Windows I really forget to update each day. The alert goes away too fast and no other indicator shows the availability of a new update. Perhaps the alert could be made sticky after three shown alerts with no user action?

Comment 38

[Caio Tiago Oliveira (asrail)]

If most users won't update until a sticky alert is raised, the alert is not good.

So we should first consider making it more visible, yet not intrusive (non-modal, non-confusing).

Right?

Comment 39

[Gabriel Chadwick]

(In reply to comment #37)
> After some days of experience with the new "toast" update alert on Windows I
> really forget to update each day. The alert goes away too fast and no other
> indicator shows the availability of a new update. Perhaps the alert could be
> made sticky after three shown alerts with no user action?
> 

I really think updating on reboot and nagging after 24h will be more then enough for the usual security update on branch. I think the goals is not to help nightly testers get the update as fast as possible the goal is to not disturb the user in the usual workflow and still get the security update in a reasonable time. A typical user will not keep the browser open for very long so the update will get applied any way and in a timely manner. The only thing maybe necessary is to get the 1 day nagger to be more agressive (is it modal ? maybe it should be).

Comment 40

[Mike Connor [:mconnor]]

Dao, re: the Later button, I think for simplicity it could just be Not Now (a la pwmgr) or simply Close, since Cancel doesn't cancel the update.  We should also kill the modal dialog you get when you click that.

If this is all that's left, can we get a patch today?

Comment 41

[Dão Gottwald [:dao]]

Attachment: rename the "Later" button, remove the modal dialog

Comment 42

[Dão Gottwald [:dao]]

Comment on attachment 299252 [details] [diff] [review]
rename the "Later" button, remove the modal dialog

Ooops, need a different access key, N is already taken...

Comment 43

[Dão Gottwald [:dao]]

Attachment: rename the "Later" button, remove the modal dialog (v2)

Comment 44

[Mike Connor [:mconnor]]

Comment on attachment 299253 [details] [diff] [review]
rename the "Later" button, remove the modal dialog (v2)

r=me, ui-r=beltzner over my shoulder, let's ship it

Comment 45

[Reed Loden [:reed]]

Checking in toolkit/locales/en-US/chrome/mozapps/update/updates.properties;
/cvsroot/mozilla/toolkit/locales/en-US/chrome/mozapps/update/updates.properties,v  <--  updates.properties
new revision: 1.37; previous revision: 1.36
done
Checking in toolkit/mozapps/update/content/updates.js;
/cvsroot/mozilla/toolkit/mozapps/update/content/updates.js,v  <--  updates.js
new revision: 1.80; previous revision: 1.79
done

Comment 46

[Eric Shepherd [:sheppy]]

What in here requires a developer documentation update?  This looks strictly like a UI change to me.

Comment 47

[Dão Gottwald [:dao]]

The interesting change is in nsIUpdatePrompt, which was already modified in bug 351471.
Compared to 1.8, the optional |background| parameter has been added to the showUpdateDownloaded method. If present, we don't show the old prompt window but a small nsIAlertService notification. Clicking it will open the prompt window. If you ignore the notification, the prompt will be shown 12 hours after the notification when the user has been idle for at least one minute.
showUpdateAvailable was changed similarly, but it does not have an extra parameter -- it will always start with the notification (e.g. attachment 302541 [details]) before showing the prompt.

Comment 48

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #47)
> but a small nsIAlertService notification. Clicking it will open the prompt
> window. If you ignore the notification, the prompt will be shown 12 hours after
> the notification when the user has been idle for at least one minute.

Really sure? I still don't see this with my nightly build at work. Does it make a problem when having set the pref to not automatically download the upgrade?

Comment 49

[Eric Shepherd [:sheppy]]

Ah-ha.  This interface isn't presently documented at all, so it's no wonder I couldn't figure out what needed updating. :)

Comment 50

[Dão Gottwald [:dao]]

(In reply to comment #48)
If you disabled automatic update, the "update available" part is for you. The 12 hours will start over after restarting Firefox. That is, you'll get the small notification again.
Obviously, it isn't optimized for nightly builds. I think it's still good enough, but you can tweak it by modifying the hidden prefs.

(In reply to comment #49)
> Ah-ha.  This interface isn't presently documented at all, so it's no wonder I
> couldn't figure out what needed updating. :)

Seth pointed to <http://wiki.mozilla.org/Software_Update>, but that's not very specific about the UI and doesn't seem to define interfaces either.
So I'm not really sure if there's anything to update. For now, it's probably enough to maintain the idl file, which I think I did.

Comment 52

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #50)
> If you disabled automatic update, the "update available" part is for you. The
> 12 hours will start over after restarting Firefox. That is, you'll get the
> small notification again.
> Obviously, it isn't optimized for nightly builds. I think it's still good
> enough, but you can tweak it by modifying the hidden prefs.

Dao, what do you mean with "it isn't optimized for nightly builds"? Shouldn't there be any difference to the beta and release channel? If updates are available the user should still be notified.

My experience from the last days are following:

Currently I have the build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022404 Minefield/3.0b4pre ID:2008022404 and Automatic Download and Update is enabled. I don't know if there were any pop-up notifications within the tray the last days because I'm not every time in front of the pc. Meanwhile I closed Firefox multiple times and also shutdown my pc after work. Now three days later there is no dialog which informs me that a new version is available. It even doesn't get automatically downloaded. If I manually check for updates I can download the new version but it doesn't happen automatically. Having a look inside the update folder on disk shows me that updates.xml is dated to 25th February at around 10am and wasn't updated anymore.

Should I file a new bug about this issue?

Comment 53

[Dão Gottwald [:dao]]

(In reply to comment #52)
> Dao, what do you mean with "it isn't optimized for nightly builds"? Shouldn't
> there be any difference to the beta and release channel? If updates are
> available the user should still be notified.

I mean that waiting 12 hours before prompting isn't ideal if you miss the initial notification and want daily updates. These 12 hours are represented by a hidden pref, app.update.promptWaitTime, independent from the update channel.


> [...] Automatic Download and Update is enabled.
> [...] It even doesn't get automatically downloaded.

This bug shouldn't have caused this and probably didn't -- the patch touches the notification code only. Please file new bug.

Comment 54

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008030607 Minefield/3.0b5pre ID:2008030607 and the same build under OS X.

Comment 55

[Eric Shepherd [:sheppy]]

Removing dev-doc-needed keyword in favor of the newly-filed bug 421636 which covers documenting the update manager interfaces.

https://bugzilla.mozilla.org/show_bug.cgi?id=421636

Comment 56

[Aakash Desai [:aakashd]]

Tracy has moved and updated the Software Update subgroup to its own Testgroup for major updates testing on litmus (from 3.0 to 3.5). Marking this as in-litmus+

Comment 57

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Aakash, which test are you referring to? I can only find https://litmus.mozilla.org/show_test.cgi?id=6673

Looking at the test shows me that we have to update its steps. Right now we say "After 10 seconds idle time on your computer you should get the Software Update Prompt..." - which is not uptodate, or?

Dao, what is the value the user has to wait until the ui pops up? Are this 60 seconds?

Comment 58

[Aakash Desai [:aakashd]]

Henrik, take a second look at litmus, it's right there in the 3.5 test run. Here's the testcase for testing the 60 second timer. Click on its testgroup to see the rest of the testcases (and subgroup(s)) that have been created by Tracy.

https://litmus.mozilla.org/show_test.cgi?id=6731

Comment 59

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This bug is not only for major updates. It also affects security and stability updates. Means the tests inside the software update subgroups also have to be updated.

Comment 60

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

Historical note: neither I nor mconnor ever realized that this codepath would also affect *major* updates. The ui-r granted was for a behavioural change for *minor* updates only.

Gory details of fallout in bug 534090, but thought I'd make a note here: not huge success. ;)