Closed
Bug 300089
Opened 20 years ago
Closed 19 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•20 years ago
|
Version: unspecified → Trunk
Comment 1•20 years ago
|
||
Ben, can you take this bug?
Comment 2•20 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•20 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•20 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•20 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Assignee | ||
Comment 7•20 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•20 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•20 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•20 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•20 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•20 years ago
|
||
Just confirming what's been said... wait an hour after the build is out or
updater loops.
Comment 15•20 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•20 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•20 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•20 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•20 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•20 years ago
|
Whiteboard: ETA: 8/2
Comment 20•20 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•19 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•19 years ago
|
Whiteboard: ETA: 8/2 → [1.8 Branch ETA 8/7]
Assignee | ||
Comment 22•19 years ago
|
||
Does this still happen with recent nightlies?
Comment 23•19 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•19 years ago
|
||
More aggressively clean up activeupdates.xml if downloadUpdates fails.
Attachment #191759 -
Flags: review?(darin)
Comment 25•19 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•19 years ago
|
||
patch for checkin
Assignee | ||
Comment 27•19 years ago
|
||
OK, I think this is now fixed.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 28•19 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•19 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•16 years ago
|
Product: Firefox → Toolkit
You need to log in
before you can comment on or make changes to this bug.
Description
•