Closed
Bug 497578
Opened 15 years ago
Closed 15 years ago
Fallback upgrade ends in endless loop of downloading partial upgrades when Private Browsing auto-start is enabled
Categories
(Toolkit :: Application Update, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.9.2a1
People
(Reporter: whimboo, Assigned: robert.strong.bugs)
References
Details
(Keywords: regression, testcase, verified1.9.1)
Attachments
(5 files, 5 obsolete files)
(deleted),
image/jpeg
|
Details | |
(deleted),
application/force-download
|
Details | |
(deleted),
patch
|
robert.strong.bugs
:
review+
beltzner
:
approval1.9.1+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
robert.strong.bugs
:
review+
|
Details | Diff | Splinter Review |
(deleted),
patch
|
robert.strong.bugs
:
review+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4) Gecko/20090423 Firefox/3.5b4 ID:20090423191946
While we were sitting on update testing last week for b99 I was noticing that for one of my profiles the fallback method doesn't work. Each time Firefox claimed that the update could not be applied but didn't wanted to download the full update. Instead I ended in an infinite loop in downloading partial updates.
The following steps can be made to reproduce the loop on all platforms. The mentioned profile I will upload immediately.
Steps:
1. Start Firefox 3.5b4 with the given profile
2. Check for new updates
3. Download partial updates and don't restart Firefox
4. Close Firefox manually
5. Remove the first characters from the downloaded updates.mar file
6. Start Firefox again
7. Notice the warning dialog that the update could not be applied because an unkown reason.
8. There is no Next button to start the full download
9. Check for new updates
10. Start the download
After step 10 you will see that Firefox is downloading the partial update again. You can repeat those steps as often as you want. It's an endless loop. The following messages were added by the application updater. See the attached picture.
Flags: blocking1.9.2?
Reporter | ||
Comment 1•15 years ago
|
||
Reporter | ||
Comment 2•15 years ago
|
||
I reduced the profile as much as I had time for the last hour. I hope it's enough to see why we are failing.
Keywords: testcase
Summary: Fallback upgrade ends in endless loop of downloading of partial patch for given profile → Fallback upgrade ends in endless loop of downloading partial upgrades for given profile
Assignee | ||
Comment 3•15 years ago
|
||
Henrik, could you verify that setting the pref
user_pref("browser.privatebrowsing.autostart", true);
causes this? Thanks
Assignee | ||
Updated•15 years ago
|
Flags: blocking1.9.1?
Assignee | ||
Comment 4•15 years ago
|
||
Double checked on a new profile with setting browser.privatebrowsing.autostart to true and I was able to reproduce this bug. :(
tbqh, I would settle for a relnote here, if I thought anyone would read them!
Reporter | ||
Comment 6•15 years ago
|
||
Thanks Robert for the remaining investigation. This pref was an accidentally left-over from bug verifications of PB bugs. It's strange that this can cause such a trouble. Lets update the summary.
Summary: Fallback upgrade ends in endless loop of downloading partial upgrades for given profile → Fallback upgrade ends in endless loop of downloading partial upgrades when Private Browsing auto-start is enabled
Reporter | ||
Comment 7•15 years ago
|
||
(In reply to comment #5)
> tbqh, I would settle for a relnote here, if I thought anyone would read them!
What's the chance that people will hit this situation? Do we know how often partial updates fail?
Does it need to download a corrupt partial, or would any network failure during the partial DL cause this?
Comment 9•15 years ago
|
||
Partials fail for a bunch of reasons, but not all that often. Don't think this blocks, but would obviously like a fix, and to understand what we're blowing away in private browsing that causes this to happen.
Assignee | ||
Comment 10•15 years ago
|
||
A corrupted download is handled by the file hash check so the case where I see that this would happen is when a file to be updated has been changed and the crc check then failed.
Reporter | ||
Updated•15 years ago
|
Keywords: regression
Comment 11•15 years ago
|
||
From talking to the Numerator and build and release people, the ratio of partials:completes might be around 2:1, for the last few versions. Which is sort of a big number of completes and could indicate a rather large number of partial failures. We're in the middle of 3.0.11 release, but there it is for your consideration.
Assignee | ||
Comment 12•15 years ago
|
||
Also note that if a person is not running the latest version their next update will be a complete
Comment 13•15 years ago
|
||
My original question to the Numerator was: what is the number of partial vs complete updates for the latest version prior update offer. 2:1 seems too many completes, but we could sift through the data we have.
Assignee | ||
Comment 14•15 years ago
|
||
Per mconnor when entering private browsing necko is reset which is causing the XHR to return NS_ERROR_NOT_INITIALIZED in onStopRequest. With the browser.privatebrowsing.autostart pref added by bug 460346 set to true necko is reset on startup while the XHR is being made by app update. The app update XHR request can be moved to final-ui-startup (the same point session restore uses to avoid similar issues) to fix this bug and it is my understanding that private browsing will be fixing the necko reset at some point in the future. Patch coming up.
Assignee | ||
Comment 15•15 years ago
|
||
Assignee: nobody → robert.bugzilla
Status: NEW → ASSIGNED
Attachment #382863 -
Flags: review?(mconnor)
Comment 16•15 years ago
|
||
Comment on attachment 382863 [details] [diff] [review]
patch rev1
r=me, but the comment should just list the items that we'll do on final-ui-startup, the current wording is a little strange
Attachment #382863 -
Flags: review?(mconnor) → review+
Assignee | ||
Comment 17•15 years ago
|
||
Carrying forward review
Attachment #382863 -
Attachment is obsolete: true
Attachment #382879 -
Flags: review+
Assignee | ||
Updated•15 years ago
|
Attachment #382879 -
Flags: approval1.9.1?
Assignee | ||
Updated•15 years ago
|
Attachment #382879 -
Attachment is obsolete: true
Attachment #382879 -
Flags: approval1.9.1?
Assignee | ||
Comment 18•15 years ago
|
||
Some cruft snuck in to the change to the test head file
Attachment #382885 -
Flags: review+
Attachment #382885 -
Flags: approval1.9.1?
Comment 19•15 years ago
|
||
Comment on attachment 382885 [details] [diff] [review]
patch rev3
a191=beltzner
Rob tells me he might have an alternate fix, but this seems pretty straightforward and solid to me. Seems to have passed unit tests on tryserver, too.
Attachment #382885 -
Flags: approval1.9.1? → approval1.9.1+
Comment 20•15 years ago
|
||
Reporter | ||
Comment 21•15 years ago
|
||
I don't think that we can have an automated test for this problem, or? If it's not possible shall we create at least a Litmus test? I know that this is very specific but it would give us the chance to cover regressions. We don't have a test for fallback upgrades until now.
Target Milestone: --- → mozilla1.9.2a1
Assignee | ||
Comment 22•15 years ago
|
||
(In reply to comment #19)
> (From update of attachment 382885 [details] [diff] [review])
> a191=beltzner
>
> Rob tells me he might have an alternate fix, but this seems pretty
> straightforward and solid to me. Seems to have passed unit tests on tryserver,
> too.
I'm more comfortable with the current fix than the alternative at present. I'll look at the alternative after the 3.5 release since it is cleaner though more invasive.
Gavin, thanks for the checkin!
Henrik, thanks for catching this... I'm looking into adding a test but it won't be finished soon so a litmus test would be a good thing if it isn't too much trouble.
Comment 23•15 years ago
|
||
(removing relnote keyword)
Rob: can you come up with a testing matrix that we can use to hammer away on this during the QA period?
Keywords: relnote
Assignee | ||
Comment 24•15 years ago
|
||
(In reply to comment #23)
> (removing relnote keyword)
>
> Rob: can you come up with a testing matrix that we can use to hammer away on
> this during the QA period?
Will do
Reporter | ||
Comment 25•15 years ago
|
||
Verified fixed on trunk and 1.9.1 with builds on Windows and OS X:
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090613 Minefield/3.6a1pre ID:20090613032901
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090613 Shiretoko/3.5pre ID:20090613031011
Robert, that was a really quick fix. Thanks you too.
Status: RESOLVED → VERIFIED
Flags: in-testsuite?
Flags: in-litmus?
Flags: blocking1.9.2?
Keywords: fixed1.9.1 → verified1.9.1
Assignee | ||
Comment 26•15 years ago
|
||
Assignee | ||
Comment 27•15 years ago
|
||
Attachment #384013 -
Attachment is obsolete: true
Assignee | ||
Updated•15 years ago
|
Attachment #384044 -
Flags: review?(dtownsend)
Assignee | ||
Comment 28•15 years ago
|
||
I'll file a separate bug for the minor change to nsUpdateService.js.in
Attachment #384044 -
Attachment is obsolete: true
Attachment #384464 -
Flags: review?(dtownsend)
Attachment #384044 -
Flags: review?(dtownsend)
Assignee | ||
Comment 29•15 years ago
|
||
(In reply to comment #28)
> Created an attachment (id=384464) [details]
> patch - tests
>
> I'll file a separate bug for the minor change to nsUpdateService.js.in
Filed bug 499770
Reporter | ||
Comment 30•15 years ago
|
||
Robert, seeing your work on the test makes me wonder if we still should add a litmus test for it. When do you think the test will be ready?
Assignee | ||
Comment 31•15 years ago
|
||
Hopefully soon so you might as well hold off
Comment 32•15 years ago
|
||
Why is the xpcom-shutdown notification commented out in end_test?
Assignee | ||
Comment 33•15 years ago
|
||
It was cruft that snuck in while I was working on bug 499770
Comment 34•15 years ago
|
||
Comment on attachment 384464 [details] [diff] [review]
patch - tests
I guess you don't need that or the hunk in head_update.js with the other patch landed.
Attachment #384464 -
Flags: review?(dtownsend) → review+
Assignee | ||
Comment 35•15 years ago
|
||
exactly
Assignee | ||
Comment 36•15 years ago
|
||
Attachment #384464 -
Attachment is obsolete: true
Attachment #384690 -
Flags: review+
Assignee | ||
Comment 37•15 years ago
|
||
Test patch pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/07fb0b9396fa
Flags: in-testsuite?
Flags: in-testsuite+
Flags: in-litmus?
Assignee | ||
Comment 38•15 years ago
|
||
Attachment #384753 -
Flags: review+
Assignee | ||
Comment 39•15 years ago
|
||
Test patch pushed to mozilla-1.9.1
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/8d1d8901c213
Assignee | ||
Comment 40•15 years ago
|
||
Now that bug 496335 is fixed this workaround is going to be removed in bug 512651
You need to log in
before you can comment on or make changes to this bug.
Description
•