263388 - Downloads initiated in hidden iframe doesn't work

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Pavel Penaz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041007 Firefox/0.10
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041007 Firefox/0.10

On the above page a popup is blocked, which contains an exe file download. But
still download dialog appears and is not functional. When you click to download
the file, the download windows disappears and nothing happens..

Reproducible: Always
Steps to Reproduce:
1. Go to the page: http://thenewsearch.com/thenewsearch.html
2. Click OK in the download window

Actual Results:  
Download window disappears and the file is not downloaded

Expected Results:  
Either 

1. the file should get saved

or

2. the download window should be blocked by FF popup blocker

Comment 1

[Pavel Penaz]

Just a side note, be careful with the exe file. It is a dialer so do not try to
open it.

Comment 2

[Ryan Polk (Quark)]

The file download is not in a popup, it's in an iframe.  The download is
functional, Firefox's download manager (Tools -> Downloads or Ctrl+J) shows your
download history.  It's not allowed to be opened because it's an .exe, as a
security precaution.

As far as I see, everything here is working as intended.

Comment 3

[Pavel Penaz]

With a clean profile I still get the same behaviour. If I turn off the popup
blocker, everything works fine and i can either save or cancel the download. But
with the popup blocker enabled the save dialog shows up but I am not able to
save the file, the download window disappears after I click OK before I can even
choose location to save the file to.

If I click in the popup notification area and I click on the item to show the
popup, the download window appears again and this time it works and I am able to
save the file.

Comment 4

[Pavel Penaz]

Reopening the bug to get noticed. I've played with this problem on a clean
install of WinXP and Firefox and I have found the following. This issue only
shows up if you have Firefox set to "ask me where to save every file", then the
download window does not do anything. If you have FF set to "automatically save
downloads" than it works properly.

Comment 5

[Pavel Penaz]

I managed to reproduce this on WinXP with Mozilla (clean install, new profile).
You have to have popup blocker enabled to be able to reproduce this bug..

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041008

Comment 6

[Ryan Polk (Quark)]

1)Enable Popup blocker
2)Make sure "Ask me where to save..." is enabled

The download is not in the popup, but somehow the blocking the popup is causing
it to fail.  Since the popup blocker seems to cause the problem, I'll throw this
in that component.  Since you said this happened in Suite -> Browser.  Thanks
for your persistance and a better report of why.

I wonder if this happened before the popup blocking changes?

JS Console:
Error: [Exception... "Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIFilePicker.init]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
file:///C:/MOZILLA/CLEANA~1/MOZILLA/DIST/BIN/components/nsHelperAppDlg.js ::
anonymous :: line 155"  data: no]
Source File:
file:///C:/MOZILLA/CLEANA~1/MOZILLA/DIST/BIN/components/nsHelperAppDlg.js
Line: 155

Comment 7

[Matthias Versen [:Matti]]

-> Firefox

Comment 8

[Ryan Polk (Quark)]

Back to Browser, as the reporter says and I just verified, this ALSO affects Suite.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Something really fishy is up here.  jst, wladimir, could you check this out?

Comment 10

[Johnny Stenback (:jst)]

Hmm, in a firefox (winxp) branch build from today I get a functioning download
dialog, if I click ok, firefox downloads the file n' all.

Comment 11

[Johnny Stenback (:jst)]

This site is feeding its visitors this exe file in a frame, *and* as a popup.
The one that comes as the content of a frame we display the download dialog for,
but the popup is just blocked. I don't see how this can have anything to do with
the popup blocker...

Comment 12

[Pavel Penaz]

Can anyone confirm that this bug is fixed with todays latest Tinderbox branch
build? Or perhaps the site has changed its content. Now when I load the page it
loads fine, download dialog does not automatically show up. Download dialog
shows up only when I allow the popup from the information bar. Anyone?

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041014
Firefox/0.10

Comment 13

[Pavel Penaz]

Please ignore my above comment, now I get the download dialog from frame again
and it still does not work.. 

Comment 14

[Wladimir Palant]

Testing in Firefox 0.10.1 - the site opens a download dialog from both frame and
popup. It works from the popup but not from the frame *regardless the popup
blocker setting*. This definitely doesn't have anything to do with the popup
blocker.

JS Console shows an exception (NS_ERROR_FAILURE) in nsHelperAppDlg.js for this line:

picker.init(parent, windowTitle, nsIFilePicker.modeSave);

nsIFilePicker obviously doesn't like getting a frame instead of a window.
Changing it to this fixes the problem:

picker.init(parent.top, windowTitle, nsIFilePicker.modeSave);

Comment 15

[Wladimir Palant]

Attachment: Testcase

This tries to open a download dialog from an invisible iframe. Firefox 0.10.1
and Mozilla 1.8a4 fail to open the file picker when requested to save the file
(in Firefox "Ask me where to save every file" has to be enabled in the
preferences). Mozilla 1.7.3 isn't affected by the bug for some reason (on
Windows, might be OS-dependent).

Comment 16

[Wladimir Palant]

Attachment: FilePicker patch

I think this has to be fixed in the FilePicker - it needs to go to the parent
window if the current one doesn't have a widget associated with it. There might
be a better way to do this of course, my code is mostly Copy&Paste from
nsGlobalWindow::GetParent().

nsBaseFilePicker.cpp has the same version for trunk and aviary, so this patch
should be appliable to both.

Comment 17

[Wladimir Palant]

Comment on attachment 162171 [details] [diff] [review]
FilePicker patch

This seems to be a regression from bug 256235, asking jst to review.

Comment 18

[Wladimir Palant]

Patch from bug 256235 hasn't been checked in on the 1.7 branch, so it isn't
affected. Removing blocking1.7.x request.

Comment 19

[Johnny Stenback (:jst)]

Comment on attachment 162171 [details] [diff] [review]
FilePicker patch

r=jst

Comment 20

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 162171 [details] [diff] [review]
FilePicker patch

>Index: widget/src/xpwidgets/nsBaseFilePicker.cpp
>+        if (!parent)
>+          return nsnull;
>+
>+        sgo = do_GetInterface(parent);

do_GI is null-safe; no need to null-check parent.

sr=bzbarsky.

Comment 21

[Johnny Stenback (:jst)]

Fixed on the trunk.

Comment 22

[Johnny Stenback (:jst)]

Updating summary.

Comment 23

[Asa Dotzler [:asa]]

trev, please include a quick explanation of what the patch does, what kind of
testing it's had and what kinds of risks are associated with taking the patch
when you request approval. doing that will help to expidite approval requests.
thanks.

Comment 24

[Wladimir Palant]

This patch fixes a regression, that has been checked into the aviary branch (bug
256235). Problem is that downloads initiated from an invisible frame fail
because it doesn't have a native widget associated with it. The patch simply
takes the parent of the frame in this case. I don't see any risks with this
approach, code is mostly Copy&Paste from nsGlobalWindow::GetParent() which works
fine. Testing - it fixes the problem, it doesn't crash on any download, there is
not much more you can test here. So far there are no bug reports about problems
with this patch on trunk.

Comment 25

[Asa Dotzler [:asa]]

Comment on attachment 162171 [details] [diff] [review]
FilePicker patch

a=asa for aviary checkin.

Comment 26

[Johnny Stenback (:jst)]

Fixed on the aviary branch.

Comment 27

[Pavel Penaz]

Verified fixed on latest FF tinderbox branch and trunk builds.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041018 Firefox/1.0