1.21 KB, application/xml
11.32 KB, text/xml
5 bytes, text/plain
2.67 KB, patch
|Details | Diff | Splinter Review|
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.
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
Uploaded as attachment the requested information.
9 years ago
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
Created attachment 440006 [details] [diff] [review] patch - revert to pre 3.6 behavior with test Forgot to add the test to the patch
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
OS: Windows 7 → All
Hardware: x86 → All
blocking1.9.2: --- → ?
status1.9.1: --- → unaffected
status1.9.2: --- → ?
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: approval184.108.40.206?
Bad regression, needed, a=beltzner for 220.127.116.11, please land on mozilla-1.9.2 and the GECKO1924_20100413_RELBRANCH
blocking1.9.2: ? → needed
status1.9.2: ? → wanted
Attachment #440006 - Flags: approval18.104.22.168? → approval22.214.171.124+
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.
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: 574374
You need to log in before you can comment on or make changes to this bug.