update is paused, can't unpause

RESOLVED FIXED

Status

()

RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: shaver, Assigned: rstrong)

Tracking

({regression, verified1.9.2})

1.9.2 Branch
regression, verified1.9.2
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(blocking1.9.2 needed, status1.9.2 .4-fixed, status1.9.1 unaffected)

Details

Attachments

(4 attachments, 1 obsolete attachment)

I'm still running

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2b6pre) Gecko/20091228 Namoroka/3.6b6pre

likely because when I go to Check For Updates, it says

( ) Paused downloading Namoroka 3.6b6pre

Clicking the |> button does nothing (it seems disabled), and restarting the browser doesn't help.

What else can I inspect to figure out why update is stuck for me?  Will avoid restarting the browser in case it jars something, though I've rebooted this machine many a time since Dec 28th.
Try adding a boolean pref with the name app.update.log and a value of true. The error console might provide some insight
AUS:UI gUpdates:onLoad - setting current page to startpage downloading
AUS:SVC readStatusFile - status: null, path: C:\Users\shaver\AppData\Local\Mozilla\Firefox\Minefield\updates\0\update.status
AUS:SVC Downloader:_selectPatch - found existing patch with state: null
AUS:SVC Downloader:_selectPatch - failed to apply complete patch!
AUS:SVC Downloader:downloadUpdate - no patch to download
AUS:SVC readStatusFile - status: null, path: C:\Users\shaver\AppData\Local\Mozilla\Firefox\Minefield\updates\0\update.status
I was able to reproduce by deleting the active-update.xml and updates.xml. Shaver, by chance did you do this?
Not intentionally, at least.  I can check if they're there on that laptop when I get home, if I remember.
They'll likely get recreated but attaching them to this bug might shed some light. Also, attaching the update.status file might help.
The good news is that I believe I have one of my installs in this state which I can use to compare against your files and diagnose this.

Comment 7

9 years ago
I have the same problem. It occured while performing and update from 3.6.2 to 3.6.3.
Is there a way to restart the download ?
David, if you don't mind could you attach (using the 'Add an attachment' link above) the active-update.xml, updates.xml, and if present the update.status files which can be located with a default Windows install as follows:

for Windows Vista and above type the following in the Start Menu search box and press return.
%LOCALAPPDATA%
Then navigate to \Mozilla\Firefox\Mozilla Firefox\updates\

for Windows prior to Windows Vista type the following in the Start Menu -> run box and press return.
%USERPROFILE%
Then navigate to \Local Settings\Application Data\Mozilla\Firefox\Mozilla Firefox\updates\

The update.status file will be located in the 0 sub-directory.

After you have done this you can delete the active-update.xml file to get things working again.

Thanks

Comment 9

9 years ago
Created attachment 436998 [details]
Active update xml file

Comment 10

9 years ago
Created attachment 436999 [details]
updates xml

Comment 11

9 years ago
Created attachment 437000 [details]
update status file

Comment 12

9 years ago
Uploaded as attachment the requested information.
Duplicate of this bug: 557136
I have an idea on how to fix this but I need to think it through a tad more.
Assignee: nobody → robert.bugzilla
Status: NEW → ASSIGNED
Attachment #437000 - Attachment mime type: application/octet-stream → text/plain
Created attachment 439997 [details] [diff] [review]
patch - revert to pre 3.6 behavior
Attachment #439997 - Flags: review?(dtownsend)
Created attachment 440006 [details] [diff] [review]
patch - revert to pre 3.6 behavior with test

Forgot to add the test to the patch
Attachment #439997 - Attachment is obsolete: true
Attachment #440006 - Flags: review?(dtownsend)
Attachment #439997 - Flags: review?(dtownsend)
note: I filed bug 560316 to improve the previous fallback behavior that this patch restores.
Attachment #440006 - Flags: review?(dtownsend) → review+
Duplicate of this bug: 559928
Blocks: 311965
Keywords: regression
OS: Windows 7 → All
Hardware: x86 → All
blocking1.9.2: --- → ?
status1.9.1: --- → unaffected
status1.9.2: --- → ?
Flags: in-testsuite?
Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/c2085ab04bfe
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Duplicate of this bug: 554916
Comment on attachment 440006 [details] [diff] [review]
patch - revert to pre 3.6 behavior with test

Drivers, this fixes a regression where the update gets into a bad state where updates can't be downloaded by reverting to the behavior in Firefox 3.5 / Gecko 1.9.1. The patch is extremely small / safe and contains a test.
Attachment #440006 - Flags: approval1.9.2.4?
Bad regression, needed, a=beltzner for 1.9.2.4, please land on mozilla-1.9.2 and the GECKO1924_20100413_RELBRANCH
blocking1.9.2: ? → needed
status1.9.2: ? → wanted
Attachment #440006 - Flags: approval1.9.2.4? → approval1.9.2.4+
Pushed to mozilla-1.9.2 default
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a326f318bfbe

Pushed to mozilla-1.9.2 GECKO1924_20100413_RELBRANCH
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/1002fd078a87
status1.9.2: wanted → .4-fixed
Pushed followup test only fix

mozilla-1.9.2 default
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/03812f38fa82

Pushed to mozilla-1.9.2 GECKO1924_20100413_RELBRANCH
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/be910b14c879
The checked in test for this is passing now. Is there a manual repro case for verifying this fix in 1.9.2 or will the unit test suffice in this instance?
The test should suffice and tests everything we can test by simulating the failure condition. If there were steps to reproduce it might provide some value manually verifying this fix but as it stands the test is as good as any manual verification.
I'm marking this as verified for 1.9.2 now then.
Keywords: verified1.9.2
This is causing test failures - please see http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.6/1271883732.1271885410.4074.gz for details. Looking for what needs to be done, should we reopen or mark as a blocker, or do we need to change the test? Or is it small problem we can deal with later. Murali made made add this comment.
Marcia, that log is from 2010/04/21 14:02:12

I fixed the test failure and stated so in comment #24
Duplicate of this bug: 570095
Duplicate of this bug: 574374
You need to log in before you can comment on or make changes to this bug.