808722 - download window save dialog loses focus after popup, then sometimes can't be restored

Status: NEW

(SeaMonkey :: Download & File Handling, defect)

Description

[bugzilla]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Firefox/16.0 SeaMonkey/2.13.2
Build ID: 20121026205451

Steps to reproduce:

On Mac OS 10.7.4 running SeaMonkey 2.13.2 ( 20121026205451 ),
with download preferences set to show download manager and "ask every time" for save dialogs,
Try to download a bank statement after logging in to wellsfargo.com (or pdf from other website that has a redirect link type that for files (they used to cause Seamonkey to only save those "session.cgi" files).


Actual results:

The save dialog pops up then focus is returned back to the main browser window (with save dialog floating on top).
This is very annoying during tax time, etc.

Also, if you make the -fatal- mistake of hitting command-d, which on a mac for save dialogs automatically selects the desktop as the save-to destination in a save dialog, you are actually firing the create bookmark command since the browser window has focus!
Now you're done, game over, because you cannot interact with any window. The bookmark create window is between the save dialog and browser windows, but nothing is click-able or interact-able with keystrokes (i.e. return/enter, command-. ).


Expected results:

The save dialog should not lose focus to the browser window that launched it.
see similar bugs at:
https://bugzilla.mozilla.org/show_bug.cgi?id=112134
https://bugzilla.mozilla.org/show_bug.cgi?id=431544

Comment 1

[Philip Chee]

Bug 112134 - Download dialog shouldn't lock browser window
Firefox fixed this in:
Bug 781973 - Use filepicker's open() instead of the obsolete show() in /browser/*
> Bug 731307 adds code to make the filepicker show method obsolete. It will still be
> supported for a very long time, but we should update our internal uses to use the new
> showAsync method instead.

We should do the same as Firefox did.

Comment 2

[Philip Chee]

CC Stefanh. Need someone on OSX to confirm this bug exists.

Comment 3

[Philip Chee]

> We should do the same as Firefox did.
this is of course Bug 796994

Comment 4

[Stefan [:stefanh]]

Yeah, I see this on 2.13.2 and trunk. Hmm, it's bad...

Comment 5

[Stefan [:stefanh]]

Looking at this a bit more, I think it's an old issue and I also think it might happen on windows. At least when looking at bug 431544. Philip, can you repro on windows?

Comment 6

[Stefan [:stefanh]]

Hmm, maybe it just happens on Mac, I see that some people have commented in bug 431544 about it being fixed on windows.

Comment 7

[Stefan [:stefanh]]

We need to fix http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/nsHelperAppDlg.js in order to fix this.

Comment 8

[Philip Chee]

Does this also happen with Firefox? If so perhaps we can get them to fix this for us.