Closed
Bug 300089
Opened 19 years ago
Closed 18 years ago
if the update check process stalls, and update window closed, deer park hangs on next attempt "paused"
Categories
(Toolkit :: Application Update, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: cacheoverflow, Assigned: bugs)
References
Details
(Whiteboard: [1.8 Branch ETA 8/7])
Attachments
(2 files)
7.30 KB,
patch
|
darin.moz
:
review+
|
Details | Diff | Splinter Review |
9.11 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050708 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050708 Firefox/1.0+ if the update process stalls, and update window closed, deer park hangs on next attempt in a "paused" mode, which now you freezes you out of re-trying the update process, even on restart of deer park Reproducible: Always Steps to Reproduce: 1. sometime when updating cannot find server, give up and close update window 2. re-try update, it hangs is "Paused" mode 3. Actual Results: hung up for good Expected Results: let user re-try updating Temporary Work-Around: you can unfreeze the "Paused" mode, and reset the updating process, so it will work again, by first closing deer park, then deleting the updates.xml and active-update.xml files
Reporter | ||
Updated•19 years ago
|
Version: unspecified → Trunk
Comment 1•19 years ago
|
||
Ben, can you take this bug?
Comment 2•19 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050711 Firefox/1.0+ ID:2005071106 I have also seen this behaviour and the work around is the method I used -> New This is particularly aparent if you try updating just after the daily build has finished as the mirror apears to be missing the build when the software update tries to get the mar file, thus causing this behaviour.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•19 years ago
|
||
Part of the problem here is that the reporter expected closing the update window to cancel the update process. What actually happens is that "close" is interpreted as "hide", and there doesn't seem to be a way to cancel. (See bug 300925 for more on "Close" vs "Hide")
*** Bug 300921 has been marked as a duplicate of this bug. ***
Some more details from my duplicate bug: After Checking for updates, the message "deer park was unable to verify the integrity of the incremental update it downloaded, so it is downloading the complete update package" appears before the update "stalls". This is NOT bug 288054 because "Allow web sites to install software" IS checked. Comment #2 is absolutely correct, when you wait approximately 30 minutes after release of a new Nightly, you do not run into this Problem. The "mirror readyness" is apparently the only reason I (and other People on Nightly MozillaZine Forum) ran into this bug. If there exists another cause, maybe bug 300921 is not a duplicate afterall...
Comment 6•19 years ago
|
||
nominating for 1.8b4. this is a major problem unless their going to turn updates off for 1.1b.
Flags: blocking1.8b4?
Updated•18 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Assignee | ||
Comment 7•18 years ago
|
||
Reporter: When you say "update" process do you mean update check process or update download process? (I assume the latter)
Assignee: nobody → bugs
From my duplicate bug 300921: -After Checking for updates, the message "deer park was unable to verify the integrity of the incremental update it downloaded, so it is downloading the complete update package" appears. After that, update is stuck for good with the message "Connecting to the update server" with all buttons grayed out exept "Close". Restart of Firefox does not help.- So this happens after the initial update check connection to the server, but before download of a new nightly does start, progression status bar is not coming up. (IF it is the same bug i see)
Reporter | ||
Comment 10•18 years ago
|
||
it is the update check process that is the problem, not the actual downloading. If the process makes it as far as to begin the actual download, then the process will be successful every time. This behavior tends to happen when a fresh build has just become available for updating. If, say, an hour or two has elapsed since the new build was put on the update server, then the update check process tends to be successful and not get hung.
Assignee | ||
Comment 11•18 years ago
|
||
Thanks - other people commenting here: if the bug you're seeing is related to the downloading phase, please file separate bugs. This bug is related to the checking phase.
Summary: if the update process stalls, and update window closed, deer park hangs on next attempt "paused" → if the update check process stalls, and update window closed, deer park hangs on next attempt "paused"
Reporter | ||
Comment 12•18 years ago
|
||
the behavior I am seeing (and trying to describe) is exactly the same behavior as that described by Stebs in Additional Comment #8 ---------- also -- I was using version 20050712 (alpha 2 released version) and earlier until today, so I will update to latest trunk, since you request testing using test a nightly after July 23, and see if problem persists.
Comment 13•18 years ago
|
||
Bug didn't happen to me the last days, but this mustn't mean anything since one has to do the Update Check not later than (i would say) 10-20 Minutes after the Nightly is visible in Tinderbox -something that obviously only happens when you dont want it to happen ;) Gonna try to catch that time-window the next days and also spread the word on Mozillazine to watch out for this...
Comment 14•18 years ago
|
||
Just confirming what's been said... wait an hour after the build is out or updater loops.
Comment 15•18 years ago
|
||
Ben, how does one tell if it's the "checking phase" or the "download phase". The problems I'm seeing are exactly as described in comment #5. It appears to still fall within what the bug is describing.
Comment 16•18 years ago
|
||
Problem still occurs, just tried to update to today's nightly (from Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050725 Firefox/1.0+ ID:2005072506). Software Update Window shows: Paused downloading Deer Park 1.0+ Connecting to update server...
Reporter | ||
Comment 17•18 years ago
|
||
This is just a note to make sure everyone knows the temporary work-around: you can unfreeze the "Paused" mode, and reset the updating process, so it will work again, by first closing deer park, and then deleting the updates.xml and active-update.xml files (in Windows, the files are normally located in the C:\Program Files\Deer Park Alpha 2 folder) then restart Deer Park then you will be able to try the update process again, though you might want to wait 15 minutes or more after the failed attempt
Comment 18•18 years ago
|
||
Confirming the issue on a Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050726 Firefox/1.0+ ID:2005072606 build.
Comment 19•18 years ago
|
||
Today I catched the Nightly in the right time: Nightly is out on 7:14:47 and I tried Update on 7:23:09 (Times from Tinderbox) Run straight into the bug with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050727 Firefox/1.0+ ID:2005072721 So this is definitely reproducible, you just have to do the Update Check the right (or I should say wrong) time.
Assignee | ||
Updated•18 years ago
|
Whiteboard: ETA: 8/2
Comment 20•18 years ago
|
||
Can confirm - Win XP Pro SP2, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050726 Firefox/1.0+ Just note that for me, deleting the active-update.xml was all it took. I didn't need to delete the update.xml This also happened after it said it was unable to verify so it had to download the whole shebang. I found it odd at the time, since the whole thing is downloaded by default...
Comment 21•18 years ago
|
||
Confirming with Win XP Pro SP2, Thunderbird Alpha 2+ (20050726) Just to confirm I had same problem as Brian (Comment #20), i.e. it said it was unable to verify the incremental update so it had to download the whole thing and then it hung...except this happened in Thunderbird But deleting the updates.xml and active-update.xml files worked.
Assignee | ||
Updated•18 years ago
|
Whiteboard: ETA: 8/2 → [1.8 Branch ETA 8/7]
Assignee | ||
Comment 22•18 years ago
|
||
Does this still happen with recent nightlies?
Comment 23•18 years ago
|
||
Yes, had it 2 days ago with an hourly with your Update checkins (Bug 302059 etc) in it and updating to the Nightly from that day (20050804). Also from 20050805 -> 20050806 (today). Nightly comes out exactly the time I am used to check for updates ;) (around 4 pm here) Maybe holding back the info to the Update check that an Nightly is out (for something like 45 minutes) would fix it?
Assignee | ||
Comment 24•18 years ago
|
||
More aggressively clean up activeupdates.xml if downloadUpdates fails.
Attachment #191759 -
Flags: review?(darin)
Comment 25•18 years ago
|
||
Comment on attachment 191759 [details] [diff] [review] patch r=darin w/ the tweak for that thing you mentioned ;-)
Attachment #191759 -
Flags: review?(darin) → review+
Assignee | ||
Comment 26•18 years ago
|
||
patch for checkin
Assignee | ||
Comment 27•18 years ago
|
||
OK, I think this is now fixed.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Comment 28•18 years ago
|
||
This is better now. Tested with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050806 Firefox/1.0+ ID:2005080600 and update to Nightly 2005080606 Still see "Deer Park was unable to verify the integrity of the incremental update it downloaded, so it is now downloading the complete update package" Message while in update State "Downloading the update..." "Connecting to the update server..." But now, clicking on "Hide" and trying "check for Updates..." again, it starts from new with the "A new version of Deer Park is available:" etc. Did run this cycle several times until Mirrors seemed to be ready and real download began - So this really seems to be fixed (kind of). BTW, had the "Deer Park was unable to verify..." bug this time already while Tinderbox showed the Nightly to be still compiling...
Comment 29•18 years ago
|
||
I still see this descriped bug sometimes in newest thunderbird branch builds if I abort a download of the complete mar-file and restart thunderbird.
Updated•15 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•