and the update UI totally fails... looks like another old bug that just hasn't hit us before. Happens when trying to set the statusText this._update.statusText = message http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/nsUpdateService.js#2513

Comment on attachment 472125 [details] [diff] [review] patch rev1 hmmm... I can add a test for this

For reference, this is what happens on trunk when this fails... the downloading page doesn't go to the errors page.

dolske, could you please review this? A couple of notes: I cleaned up a couple of tests that aren't part of this bug so they would create the active-update.xml with the correct value for isCompleteUpdate for the update. The isCompleteUpdate value would get set correctly by the update service later but I wanted to fix it so the initial value was correct since it could potentially hide a bug that wouldn't get caught by the tests. I had to change gWindowObserver so it always added a load listener for every window opened since an alert will be displayed before the update UI for test_0074_notify_verifyFailPartial_successComplete.xul.

(In reply to comment #5) >... > I had to change gWindowObserver so it always added a load listener for every > window opened since an alert will be displayed before the update UI for s/alert/alert service notification/

Comment on attachment 472333 [details] [diff] [review] patch rev1 with tests Talked with Dave and he said he could review this.

When this happens does the user get updated or does it error out? Do we really need to take this on 1.9.1 as well? If so, then this wasn't fallout from backporting update changes from trunk?

When this happens with a manual check the UI breaks in that the UI is stuck on the page in the screenshot or if the client hides the ui during the download the user won't be notified of the error. This does affect 1.9.1. This pre-existed the backport of update changes from trunk and is not fallout from the backporting of changes from the trunk to 1.9.2. This bug will happen if releng released an update with a different file hash than the one in the update snippet which is extremely unlikely hence why this has never been caught before. It would also happen if the client had software that modified in a non-fatal way since that would change the file hash and in this case the user would get stuck in the ui shown in the screenshot. I don't think it is critical to fix this on 1.9.2 but since the changes on the client side are rather minimal and the changes are well tested I think it is a good candidate for 1.9.2. Since 1.9.1 doesn't have the app update test infrastructure I would prefer not fixing this on 1.9.1.

btw: I am slightly concerned that this bug has manifested itself in other broken behavior in the past and is possibly the cause of other bugs that I haven't been able to determine the root cause for.

Pushed to mozilla-central http://hg.mozilla.org/mozilla-central/rev/23b8229b4cef

Not "blocking" 1.9.2 but it sounds worth taking if you come up with a backported patch and request approval.

Forgot to disable debugging

Pushed to mozilla-1.9.2 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c6b6251bbbb4