918000 - Cannot download new version of iTunes from the Apple website

Status: RESOLVED DUPLICATE of bug 1115248

(Firefox :: Downloads Panel, defect)

Description

[Marco Bonardo [:mak]]

I can reproduce this on a new profile.

1. Check option "Always ask me where to save file" (must be true)
2. Go to http://www.apple.com/it/itunes/download/ (I guess any locale would do)
3. uncheck pointless checkboxes
4. click download
5. When the Choose folder dialog comes up, wait until the background page has refreshed
5. just in case wait another 5 seconds :) (simulating the user is choosing a folder)
6. click save

Nothing happens... no download at all.


The Browser console shows:

21:16:47.551 can't access dead object DownloadLastDir.jsm:17621:16:47.551 

[Exception... "'[JavaScript Error: "can't access dead object" {file: "resource://gre/modules/DownloadLastDir.jsm" line: 176}]' when calling method: [nsIContentPrefCallback2::handleCompletion]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: resource://gre/modules/ContentPrefService2.jsm :: safeCallback :: line 797"  data: yes] ContentPrefService2.jsm:800


the code in DownloadLastDir.jsm is:

  setFile: function (aURI, aFile) {
    if (aURI && isContentPrefEnabled()) {
      let uri = aURI instanceof Components.interfaces.nsIURI ? aURI.spec : aURI;
      let cps2 = Components.classes["@mozilla.org/content-pref/service;1"]
                           .getService(Components.interfaces.nsIContentPrefService2);
      let loadContext = this.window
                            .QueryInterface(Components.interfaces.nsIInterfaceRequestor)
                            .getInterface(Components.interfaces.nsIWebNavigation)
                            .QueryInterface(Components.interfaces.nsILoadContext);

Comment 1

[Marco Bonardo [:mak]]

the exception is raised by the let loadContext = this.window... line

Comment 2

[:Gavin Sharp [email: [e-mail]]]

<gavin> obvious thing to try would be to switch DownloadLastDir to hold on to the loadContext (and a boolean for isPrivate) rather than the window
<gavin> not sure if that would help

Comment 3

[Alice0775 White]

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/acf7f73e8b18
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121022124809
Bad:
http://hg.mozilla.org/mozilla-central/rev/48502b61a63e
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121022184211
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=acf7f73e8b18&tochange=48502b61a63e

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/8d9cff7e5c30
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121021214620
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/03cd2ad254cc
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/19.0 Firefox/19.0 ID:20121021225623
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8d9cff7e5c30&tochange=03cd2ad254cc

Regressed by:
03cd2ad254cc	Saurabh Anand — Bug 722995 - Part 2: Make DownloadLastDir.jsm use per-window privacy status instead of global service. r=ehsan

Comment 4

[Drew Willcoxon :adw]

I can reproduce the not-downloading part, but I don't get the error (although that error does make sense) because I don't get even that far.  (A Mac vs. Windows save dialog difference?)  Instead, promptForSaveToFileAsync in nsHelperAppDlg.js fails here:

> 250     var parent = aContext.QueryInterface(Components.interfaces.nsIInterfaceRequestor).getInterface(Components.interfaces.nsIDOMWindow);

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/nsHelperAppDlg.js#250

The exception is silently eaten, but a try-catch reveals it's:

[Exception... "Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsIInterfaceRequestor.getInterface]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: file:///Users/adw/fx/obj-debug/dist/NightlyDebug.app/Contents/MacOS/components/nsHelperAppDlg.js :: nsUnknownContentTypeDialog.prototype.promptForSaveToFileAsync :: line 256"  data: no]

Because the window's closed?  I'm not sure if this ever worked -- the case where the window navigates away before you press the Save File button.  At this point, nothing async has happened, and nothing is different from before http://hg.mozilla.org/mozilla-central/rev/b560513ee661 landed and added promptForSaveToFileAsync.

promptForSaveToFileAsync is called here:

http://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/nsExternalHelperAppService.cpp#2012

So apparently the mWindowContext passed in isn't safe to use after the window navigates away.

Comment 5

[:Felipe Gomes (needinfo for replies!)]

Is this the same as bug 673366? See comment 22 there

Comment 6

[:Paolo Amadini]

(In reply to :Felipe Gomes from comment #5)
> Is this the same as bug 673366? See comment 22 there

Likely so! Not sure which way to duplicate however, there is useful information on both bugs. Setting a dependency for now.

Comment 7

[Drew Willcoxon :adw]

Comment 4 looks like bug 673366, but the error in comment 0 is a different, potentially legit problem -- I just don't know how Marco ended up with it since comment 4/bug 673366 gets in the way first.

Marco, could you paste the call stack when that error is hit?  That would help me narrow down how this is happening.

Comment 8

[Marco Bonardo [:mak]]

(In reply to Drew Willcoxon :adw from comment #7)
> I just don't know how Marco ended up with it
> since comment 4/bug 673366 gets in the way first.

You must click very fast on the Save button when you get Save/Cancel dialog, otherwise you indeed hit bug 673366. It's a timing sensitive issue, like this one.
I will give you a stack as soon as I can make a build where downloads are working at all.

Comment 9

[Marco Bonardo [:mak]]

I couldn't find a way to copy the stack in the browser debugger and since I don't have a build atm I went manually:

conteprefs2 _get
_execStmts.handleCompletion
_onDone
cbHandleCompletion
safeCallback
exception is thrown

execStmts.handleCompletion from contenprefs2
getFileAsync
promptForSaveToFileAsync
gDownloadLastDir.setFile
this.window is DeadObject

This is catchable in the browser debugger, fwiw.

Comment 11

[cousteau]

I have exactly the same problem.  However if I go through the "What do you want to do with this file?" and "Where do you want to save this file?" dialogs real quick (in about 1 second), I manage to successfully start the download.  Once started, it continues till it ends.

Comment 12

[Robert Premuž]

So, if you use Firefox for downloading iTunes you have to practice martial arts first.

Comment 14

[:Gijs (he/him)]

Marking this as a dupe too... please undupe if tomorrow's nightly doesn't fix this.

Comment 15

[Thomas Sisson]

This is not fixed. I don't know if it is a duplicate of the Amazon issue, because I don't download Amazon music. Please reopen this and add back all of the votes on this issue. The Mozilla support page has a link to this bug. The workaround on the support page is the quickly click on the dialog box before it disappears. My finger is not that fast, and I don't want to set Firefox to download everything automatically to the same location.

Again, please!

Comment 16

[:Gijs (he/him)]

(In reply to Thomas Sisson from comment #15)
> This is not fixed. I don't know if it is a duplicate of the Amazon issue,
> because I don't download Amazon music. Please reopen this and add back all
> of the votes on this issue. The Mozilla support page has a link to this bug.
> The workaround on the support page is the quickly click on the dialog box
> before it disappears. My finger is not that fast, and I don't want to set
> Firefox to download everything automatically to the same location.
> 
> Again, please!

I tried just now, and I can't reproduce (latest Firefox 41 beta).

I fixed the Amazon bug - it was the same kind of issue as this one (the page that triggered the download was replaced by a different page), and the fixes there seemed to fix this bug, hence the marking as a duplicate. Anyway, this means I'm quite interested that there seem to be cases where this is not fixed yet. It's possible that Apple changed something in their website, too.

Please could you file a new bug with more details and let me know the bug ID?

Useful details that I would be interested in:
- exactly which page are you using to try to download iTunes? (the link in comment #0 is to the Italian one, for instance - a direct link to what you're using is helpful!)
- What version of Firefox are you testing in? (should be fixed from Firefox 38 onwards)
- Do you use permanent private browsing mode?
- Can you reproduce this issue in a new profile? ( https://support.mozilla.org/kb/profile-manager-create-and-remove-firefox-profiles )


(for various reasons I would prefer a new bug rather than reopening this one - be assured that I will do what I can to still fix the issue quickly - votes don't really strongly influence when things get fixed, which is clear enough because this bug spent 1.5 years not being addressed despite votes/duplicates)

Comment 17

[hartnegg]

Just tried with Firefox 40.0.2, it still does not work.
Why open another bug, one could just copy what the original reporter wrote.
Set Firefox to ask where to save the file, and you cannot download iTunes.
Apple reloads the page while Firefox asks where to save,
and after confirming the destination, nothing happens.

Comment 18

[:Gijs (he/him)]

(In reply to hartnegg from comment #17)
> Just tried with Firefox 40.0.2, it still does not work.
> Why open another bug, one could just copy what the original reporter wrote.
> Set Firefox to ask where to save the file, and you cannot download iTunes.
> Apple reloads the page while Firefox asks where to save,
> and after confirming the destination, nothing happens.

As I noted in my previous comment, I'd really like people to give more information. 40.0.2 - on what OS? Did you try a new profile? (with the pref in comment #0 flipped, of course)

Comment 19

[hartnegg]

Ok, wipe Firefox, wipe profile directories, install 41.0b1.

Super annoying because of all the popups and ads which I have usually disabled.
No wonder you don't gain many new users, if you treat them like this. If Firefox would have been like this when I tried it the first time, it wouldn't have survived more than one minute on my harddisk.

Then it crashes a few times, which appears to be normal now on every update.
After killing and restarting it a few times, it settles as usual, and I can start trying.

Result: If I at least click the 'save' button before the underlying page reloads, and only take too much time to choose the destination directory, then it does work now. If I click the save button too late, after the reload, then the dialog for selecting the destination appears for a fraction of a second, and immediately closes again, still not possible to save the file. This is better than before, in most cases it works.

Back to version 40.0.2. Now works always, regardless of when I click where.

After some more tries, it has forgotten that it was set to always ask, so I configure this option again. Now it behaves like 41.0b1 did. Works if I do at least the first click early enough, closes the dialog for destination selection when the first click was too late.

Again wipe profile, start 40.0.2, set option to ask, download iTunes, click save late, fails.

Again wipe profile, start 40.0.2, set option to ask, download iTunes, click save late, works.

This behaviour is chaotic, not reproducable. I give up.

Comment 20

[:Gijs (he/him)]

(In reply to hartnegg from comment #19)
> Ok, wipe Firefox, wipe profile directories, install 41.0b1.

You didn't need to do that - you can create a new profile without affecting your current install...

> Then it crashes a few times, which appears to be normal now on every update.
> After killing and restarting it a few times, it settles as usual, and I can
> start trying.

I hope you submitted crash reports so we can fix the crashes.

> Result: If I at least click the 'save' button before the underlying page
> reloads, and only take too much time to choose the destination directory,
> then it does work now. If I click the save button too late, after the
> reload, then the dialog for selecting the destination appears for a fraction
> of a second, and immediately closes again, still not possible to save the
> file.

I can reproduce this. I filed bug 1196144 to track this problem.