Closed Bug 300089 Opened 18 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)

Product:
Toolkit
Component:
Application Update
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: cacheoverflow, Assigned: bugs)

References

Details

(Whiteboard: [1.8 Branch ETA 8/7])

Attachments

(2 files)

patch
7.30 KB, patch
darin.moz
: review+
Details | Diff | Splinter Review
patch
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
Version: unspecified → Trunk
Ben, can you take this bug?
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
Blocks: 290390
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...
nominating for 1.8b4. this is a major problem unless their going to turn updates
off for 1.1b.
Flags: blocking1.8b4?
Flags: blocking1.8b4? → blocking1.8b4+
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) 
Can you test with a nightly after July 23?
Status: NEW → ASSIGNED
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.
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"
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.
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...   
Just confirming what's been said... wait an hour after the build is out or
updater loops.
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.
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...
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
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.
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.
Whiteboard: ETA: 8/2
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...
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.
Whiteboard: ETA: 8/2 → [1.8 Branch ETA 8/7]
Does this still happen with recent nightlies? 
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?
Attached patch patch — — Splinter Review 
More aggressively clean up activeupdates.xml if downloadUpdates fails.
Attachment #191759 - Flags: review?(darin)
Comment on attachment 191759 [details] [diff] [review]
patch

r=darin w/ the tweak for that thing you mentioned ;-)
Attachment #191759 - Flags: review?(darin) → review+
Attached patch patch — — Splinter Review 
patch for checkin
OK, I think this is now fixed.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
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...
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.
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.