Closed Bug 650973 Opened 11 years ago Closed 11 years ago

Update dialog is seldom if ever shown on Mac OS X and Linux for complete updates

Categories

(Toolkit :: Application Update, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla6
Tracking Status
firefox5 - affected

People

(Reporter: robert.strong.bugs, Assigned: robert.strong.bugs)

Details

Attachments

(1 file, 2 obsolete files)

I believe that now that app update uses file renames the update process makes it past 50 percent complete by the time 0.5 seconds has elapsed which causes the updater dialog to not display. I fixed the same issue for Windows in bug 316890 (see bug 316890 comment #9).

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/updater/progressui_osx.mm#139
I'd call this a feature, not a bug! Well, unless the problem is that the 1st 50% is now much faster than the last 50%?
I'm pretty certain that the 1st 50% has always been faster than the last but it is even more so now with the file renames.
btw: it is being shown for partial updates
Summary: Update dialog is seldom if ever shown on Mac OS X → Update dialog is seldom if ever shown on Mac OS X for complete updates
limi and faaborg, the changes made to the updater during the Firefox 4.0 cycle made it so updates are applied significantly quicker and there is code that makes it so the updater dialog isn't displayed when applying the update if after 0.5 seconds approximately 50% of the steps to apply an update have been completed. As it stands now the updater dialog is seldom displayed during a complete update.

I made a change to the Windows updater dialog so it won't display if 60% of the steps have been completed. I'd like your take on whether Mac and Linux should also do this so the updater dialog is usually displayed when applying a complete update or if I should change Windows back so the updater dialog is usually not displayed when applying a complete update.
Keep in mind that even with silent updates there will still be the option for manual updates.
I saw this just now on Linux. I think there was a respin today and I received a complete update for it. When I next opened Nightly I couldn't work out why it was taking much longer than usual to appear.
OS: Mac OS X → All
Thanks Daniel, that is exactly the case I am concerned with and *thought* it might affect Linux as well so thanks for confirming that.
Summary: Update dialog is seldom if ever shown on Mac OS X for complete updates → Update dialog is seldom if ever shown on Mac OS X and Linux for complete updates
Attached patch patch (obsolete) — Splinter Review
Mossop, the update process is significantly faster now that it does file renames which is causing the update ui to not be shown for the last half of the update process which takes significantly longer than the first half of the update process.
Assignee: nobody → robert.bugzilla
Status: NEW → ASSIGNED
Attachment #527961 - Flags: review?(dtownsend)
This affects Aurora as well. I'm ok with not taking this for Aurora but there will likely be users that expect to see the dialog not seeing it and thereby be confused as to whether the update they downloaded was actually applied.
Attached patch patch rev1 (obsolete) — Splinter Review
accidentally set sProgress for Mac to a different value than other platforms
Attachment #527961 - Attachment is obsolete: true
Attachment #527961 - Flags: review?(dtownsend)
Attachment #527962 - Flags: review?(dtownsend)
Comment on attachment 527962 [details] [diff] [review]
patch rev1

>-  // Only show the Progress UI if the process is taking significant time.
>-  // Here we measure significant time as taking more than one second.
>-
>+  // Only show the Progress UI if the process is taking a significant amount of
>+  // time. We measure significant time as if after .5 seconds sProgress is more
>+  // than 70 out of 100.

This reads wrong to me, maybe "We consider it a significant time if after .5 seconds sProgress is still less than 70%". Same throughout
Attachment #527962 - Flags: review?(dtownsend) → review+
Re-requesting review since I went with a new comment
Attachment #527962 - Attachment is obsolete: true
Attachment #528434 - Flags: review?(dtownsend)
Attachment #528434 - Flags: review?(dtownsend) → review+
Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/75beeda41b46
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite-
Flags: in-litmus-
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
Comment on attachment 528434 [details] [diff] [review]
patch updated to comments

This affects Aurora as well. I'm ok with not taking this for Aurora but there
will likely be users that expect to see the dialog not seeing it and thereby be
confused as to whether the update they downloaded was actually applied.
Attachment #528434 - Flags: approval-mozilla-aurora?
Comment on attachment 528434 [details] [diff] [review]
patch updated to comments

let's just go with the trunk for now. thanks.
Attachment #528434 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora-
Mozilla/5.0 (X11; Linux i686; rv:6.0a1) Gecko/20110427 Firefox/6.0a1

How can I force a complete update for the next nightly to test this?
Simplest is to wait a couple of days after updating to a build with the fix and then updating.
I changed the permissions of the partial update.mar to 0000 and then deleted it after the update failed to apply. That forced a complete update and on the subsequent restart the progress dialog appeared so this is fixed for me.
You need to log in before you can comment on or make changes to this bug.