412360 - Download Manager remains empty, downloads don't start, with this 3.0b2 downloads.sqlite

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect, P3)

Description

[Steve England [:stevee]]

Attachment: downloads.sqlite file that shows strangeness

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008011407 Minefield/3.0b3pre ID:2008011407

A user came onto IRC today complaining of download problems. Their list was empty and they couldn't download new files. They were happy enough to send me the file so I could attach it to a bug, so here it is.

1. Make a new profile, quit firefox
2. Copy attached downloads.sqlite into it
3. Start Firefox
4. Tools > Downloads

Error console reports:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://mozapps/content/downloads/downloads.js :: <TOP_LEVEL> :: line 18"  data: no]

DM window appears empty.

5. Right click on an image on your start page, Save Image As

Error console reports:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://browser/content/browser.js :: anonymous :: line 907"  data: no]

Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://global/content/contentAreaUtils.js :: getTargetFile :: line 431"  data: no]

Nothing appears to get saved.

6. Tools > Options > Downloads
7. Click Browse

Error console reports:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: chrome://browser/content/preferences/main.js :: anonymous :: line 344"  data: no]

No file picker dialog appears.

The reporter was on 3.0b2, but that's as much as I know. The cause of this problem may have been fixed post-3.0b2, but I'd rather file a dupe than something gets through the net :-)

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

I'm pretty sure this is a dupe of a bug I saw a while back where large download.sqlite databases ended up meaning that new downloads wouldn't show up for a while. For some reason I think Mossop filed that bug, cc'ing him just in case.

Comment 2

[Dave Townsend [:mossop]]

My issue was just because I had so large a history that it took a long time for the downloads window to display them all, that was fixed with the incremental display code.

Comment 3

[Shawn Wilsher :sdwilsh]

can someone tell me if this still doesn't work?  We may have fixed this in a different bug (symptoms look familiar)

Comment 4

[Ed Lee :Mardak]

I believe this bug had a download that failed to autoresume.

Comment 5

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022704 Minefield/3.0b4pre ID:2008022704

Certainly if I make a new profile and drop the downloads.sqlite file into it, problems wrt the download manager are still present. But perhaps the problem that caused this downloads.sqlite to get into the state its in has been fixed, so no users will see such a problem anymore.

Comment 6

[Ed Lee :Mardak]

Attachment: v1

data:text/html,<a href="javascript:alert(5)">javascript uris fail to save</a>

Load that and alt-click it to download. webbrowserpersist and download will be added but saveURI fails without letting the nsITransfer download know about it, so the download stays in QUEUED state.

This patch fixes the problem of getting into the state of the attached downloads.sqlite by having WBP fail the download.

Also, without the nsDownloadManager change, it would also fix the problem of starting the download manager with the downloads.sqlite because the *second* time you load the download manager service, the javascript: uri download will already have been set to failed.

*With* the nsDownloadManager change, we ignore the fact that the download failed when starting, and the user will see a failed message for the download the first time they try opening the download manager.

Comment 7

[Ed Lee :Mardak]

Shawn: This might fix bug 394247 ?

Comment 8

[Shawn Wilsher :sdwilsh]

Comment on attachment 306041 [details] [diff] [review]
v1

Yeah - when I was playing in RestoreDatabaseState I was wondering if we wanted to ignore failures there.

I don't think this is really worth an automated test.

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 306041 [details] [diff] [review]
v1

+            SendErrorStatusChange(PR_TRUE, rv, nsnull, aFile);

hmm... why not pass the channel here instead of null?

Comment 10

[Ed Lee :Mardak]

Attachment: v1.1

(In reply to comment #9)
> +            SendErrorStatusChange(PR_TRUE, rv, nsnull, aFile);
> hmm... why not pass the channel here instead of null?
Sure.

Also added a test that makes sure javascript URI downloads fail instead of getting stuck.

Comment 11

[Ed Lee :Mardak]

Checking in embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp;
/cvsroot/mozilla/embedding/components/webbrowserpersist/src/nsWebBrowserPersist.cpp,v  <--  nsWebBrowserPersist.cpp
new revision: 1.135; previous revision: 1.134
done
Checking in toolkit/components/downloads/src/nsDownloadManager.cpp;
/cvsroot/mozilla/toolkit/components/downloads/src/nsDownloadManager.cpp,v  <--  nsDownloadManager.cpp
new revision: 1.170; previous revision: 1.169
done
Checking in toolkit/mozapps/downloads/tests/browser/Makefile.in;
/cvsroot/mozilla/toolkit/mozapps/downloads/tests/browser/Makefile.in,v  <--  Makefile.in
new revision: 1.18; previous revision: 1.17
done
RCS file: /cvsroot/mozilla/toolkit/mozapps/downloads/tests/browser/browser_bug_412360.js,v
done
Checking in toolkit/mozapps/downloads/tests/browser/browser_bug_412360.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/tests/browser/browser_bug_412360.js,v  <--  browser_bug_412360.js
initial revision: 1.1
done

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Any given issue in comment 0 is fixed.

Verified with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5pre) Gecko/2008030904 Minefield/3.0b5pre ID:2008030904.

Comment 13

[Shawn Wilsher :sdwilsh]

This unit test should have been an xpcshell one.  Any reason why it wasn't?