256235 - can't download files (no file picker displayed) for javascript-redirected sites -- XPSP2

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect)

Description

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Some people are reporting that:

> 1. Go to http://www.divx.com/divx/download/index.php
> 2. Click Download.
> 3. Firefox will reload the page and will ask you to download the file (save to 
> disk).
> 4. Hitting OK in the prompt will not display the Filepicker and you cannot 
> save the file.
>
> Seems to only effect:
>
> Win XP SP2 users with "Ask me where to save every file" enabled in the download 
> options on pages using javascript redirects (I apologize if that is the wrong 
> term) to download the file. 

SooOOooo, looks like it's related to my landing of bug 240723 on the aviary branch.

Not sure if it also happens with Seamonkey (post jst's landing of the
nsIFilePicker stuff, natch), but stephend the intrepid is chasing that for me.
More as I find it.

(Interesting trivia: there are 3 nsHelperAppDlg.js files pulled or produced in
the firefox build, but only one is used/shipped!)

Comment 1

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Doesn't seem to affect Seamonkey, hrm.  jst is no doubt on the money with his
comment:


------- Additional Comment #33 From Johnny Stenback 2004-08-19 22:24 PDT [reply]
-------

This comment belongs in the other bug that doesn't exist yet, so until then,
I'll put it here... Maybe the problem is that a closed window happens to be used
as the parent of a file picker, seems like that could cause this exception to be
thrown... 

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE)
[nsIFilePicker.init]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS
frame ::
file:///C:/Program%20Files/Mozilla%20Firefox/components/nsHelperAppDlg.js ::
anonymous :: line 155"  data: no]
Source File:
file:///C:/Program%20Files/Mozilla%20Firefox/components/nsHelperAppDlg.js
Line: 155

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Attachment: if we fail to init with aContext's getInterface spawn, try again with something borrowed from the window-watcher

stephend yet again came through for me, and cycled on this a half-dozen times
until I got something right enough to "fix" the problem.

jst's looking at how the parent window got into this weird state, but in the
meantime dropping this file into your <firefox dir>/components/ directory as
nsHelperAppDlg.js (the exception message will have the path in it, I suspect)
should let you download again.	I'll check in this robustification later
tonight, if someone -- or someones; tell all your forum friends! -- verifies
that it works for them.

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Attachment: that change in patch form

I bet jst would give me the old OK for this one.

Comment 5

[Johnny Stenback (:jst)]

Attachment: Alternative approach, get the widget from the docshell even if there is no presshell

This fixes the problem too. This is a trunk diff, but should apply to branch as
well.

Comment 6

[Johnny Stenback (:jst)]

Attachment: Same as above with the nsIWidget leak fixed.

Comment 7

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 156571 [details] [diff] [review]
Same as above with the nsIWidget leak fixed.

I like it.  Aviaryize as well, please!

Comment 8

[Johnny Stenback (:jst)]

Fixed on trunk and aviary branch.

Comment 9

[Ger Teunis]

Thank you all, fixed now.
Next time I'll file a bug sooner. I just was too careful, sorry for that.

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED with both Firefox 1.0 and the latest builds... (old, old bug).