Closed Bug 538533 Opened 10 years ago Closed 10 years ago

If a complete update fails the update prompt should state the error and offer a link to download the update

Categories

(Toolkit :: Application Update, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- wanted
status1.9.1 --- wanted

People

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

References

Details

(Whiteboard: [3.6.x][3.5.x])

Attachments

(2 files)

Per bug 514040 comment #8

I modified a complete mar after it was downloaded and app update offered to try to update again instead of showing the patch apply error with the link to manually update.

I don't believe this bug actually blocks or depends on the other bugs so I removed the dependencies.
Attached patch patch rev1Splinter Review
Turns out this was due to a bogus assumption in updates.js.

This also fixes bug 362548.
Attachment #420690 - Flags: review?(dtownsend)
Status: NEW → ASSIGNED
btw: I think I have found an acceptable way to test this but it will take me a couple of days to finish it.
to help with the review

For this failure case when a patch fails to apply for a partial the complete is downloaded but for the complete nothing is downloaded
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/src/nsUpdateService.js.in#1186

so checking state == STATE_DOWNLOADING in updates.js is bogus.
Attachment #420690 - Flags: review?(dtownsend) → review+
Filed bug 540046 to add a test for this bug
Whiteboard: [3.6.x][3.5.x]
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a1pre) Gecko/20100116 Minefield/3.7a1pre

Help -> Check for Updates... now fails for me (blank wizard window with just a Finish button).

Get this in the Error Console:

Error: gLogEnabled is not defined
Source File: chrome://mozapps/content/update/updates.js
Line: 95

Line 95 is:

  if (gLogEnabled) {

Clicking on the Finish button fails to close the wizard and gives:

Error: invalid 'in' operand this._pages[pageid]
Source File: chrome://mozapps/content/update/updates.js
Line: 261

Line 261 is:

    if ("onWizardFinish" in this._pages[pageid])
Depends on: 540175
Had to backout the logging changes due to scoping issues which caused bug 540175
Attachment #422029 - Flags: review+
Duplicate of this bug: 540175
changeset for the backout of the logging changes
http://hg.mozilla.org/mozilla-central/rev/57a006de51e1
Duplicate of this bug: 540253
Duplicate of this bug: 540815
Robert, is there a way to verify this fix manually on trunk? Would be good to know if that fixes bug 538372.
Target Milestone: --- → mozilla1.9.3a1
1. Install the previous nightly.
2. Check for updates / download the partial update.
3. Exit Firefox without restarting
4. Change the update.status to "failed: 6" without the quotation marks and followed by a newline.
5. Start Firefox.
6. You should be asked to download again.
7. Download the complete update.
8. Exit Firefox without restarting
9. Change the update.status to "failed: 6" without the quotation marks and followed by a newline.
10. Start Firefox.
11. You should see patch apply failure error in the UI and a link to download / install.

Note: on nightly builds we offer a different url that isn't as appropriate as the url we offer for release builds.
And if you start at 7 with a two-day old nightly you should get the same prompting behavior.
(In reply to comment #12)
> Robert, is there a way to verify this fix manually on trunk? Would be good to
> know if that fixes bug 538372.
Henrik, have you had a chance to verify this yet? I'm almost done with a couple of mochitests for this bug, would like to backport it, and would prefer it if you also verified it.
Rob, sorry for the delay but last week I had to prepare a lot of stuff for the FOSDEM.

Because I do not have time to run the tests on all platforms and with localized builds I ran the steps from your comment 13 against the de locale on OS X. After trying to apply the corrupted complete patch I get the mentioned wizard page which states about a manual download. Clicking on Help|Check for Updates again will start the process again.

I call it fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a2pre) Gecko/20100206 Minefield/3.7a2pre
Status: RESOLVED → VERIFIED
blocking1.9.2: --- → ?
I assume we need both patches? Not blocking but we'd really like it, so please get a branch patch together and request approval.

This affects 3.5 as well?
blocking1.9.2: ? → ---
This affects all previous versions of app update so yes, it affects 3.5 as well. I've got a bunch of fixes in bug 530872 that includes a couple of additional fixes to this bug. After I get that landed I'll create 3.5 / 3.6 patches for this bug that includes those fixes
Adding in‑testsuite+. I added tests for this in bug 530872
Flags: in-testsuite+
Duplicate of this bug: 571220
You need to log in before you can comment on or make changes to this bug.