Closed Bug 431544 Opened 18 years ago Closed 2 years ago

File Save As dialog opened via unknown content dialog, a focus event back to the web page gets fired

Categories

(Firefox :: File Handling, defect)

Product:
Firefox
Component:
File Handling
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
blocking2.0 --- -

People

(Reporter: bills, Unassigned)

References

(
URL
)

Details

(Keywords: access, regression)

Attachments

(4 files)

Dialogs in FF2
372.79 KB, image/png
Details
Dialogs in FF3
369.94 KB, image/png
Details
use the toplevel window instead
1.34 KB, patch
Details | Diff | Splinter Review
Firefox-Nightly-Replace-dialog.png
543.96 KB, image/png
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5 Looking at focus and foreground events with accevent with show all hidden/invisible events checked, Save As sends an extra event at the end that confuses a screen reader. There are the normal focus and foreground events when you open the dialog. Then, after a brief pause there is a focus event back to the web page. After that first bad focus, sometimes further tabbing sends more focuses to the web page, sometimes it sends further focuses back in the dialog. Reproducible: Always Steps to Reproduce: 1. start accevent. watch foreground and focus events while showing events for hidden/invisible windows. Also display the window class along with the HWND, Name and value 2. start FF3 3. Open Save As with Alt F A. Actual Results: There is a foreground followed several hidden focuses to windows that all make sense (That they are hidden is normal). Then after a brief pause, there is a focus to the currently focused control on the web page. (For google.com, that's usually "Google Search") Expected Results: No focus event to the web page while the dialog is open. This extra focus causes a screen reader to continue reading the web page while the user wants to tab through the dialog.
Alexander, this is definitely confirmed. We already have a bug on it somewhere, but I can't find it, so that's then probably a duplicate of this one (or vice versa). Please take a look and see if you can fix this without much risk.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can see the same behavior with following STR: 1. Open the web page: http://www.mozilla-europe.org/en/ 2. Click on Download 3. Press Enter to fire the "Save File" button inside the upcoming little dialog 4. The "Save File as" dialog appears With step 4 you can see the windows save as dialog but it hasn't the focus. The title bar is lightened. You have to hit Alt+Tab to put the focus into the save as dialog. This is bothersome if you are not having a mouse. I think it should be related to the information given in comment 0.
Keywords: access
Version: unspecified → Trunk
According to my experience on WinXP this doesn't always happen. I'd say in about 50-75% of all cases the focus of the save as... dialog is lost. Another thing when the focus is in the window is, that you can save only by ALT + S, not by hitting Enter (which is the expected behaviour since the Save button is highlighted). Maybe the enter button is blocked by an active object like a video player e.g. on a site from youtube, but still this shouldn't happen in the dialog.
I'm seeing this on Win XP all the time, have not yet seen it at all on Vista. This is very annoying for keyboard users. Requesting blocking.
Flags: blocking-firefox3.1?
I have to agree. It's working fine on Vista but not XP. Marco, do you know a way how to check the fired events?
(In reply to comment #5) > I have to agree. It's working fine on Vista but not XP. Marco, do you know a > way how to check the fired events? One can either do an event monitor using DOM Inspector, or use the Microsoft MSAA tools or IBM's accProbe to check the a11y events. They usually correspond to real events, and from the looks of it, a focus event is fired on some element on the page *after* the dialog has already opened.
That's not limited to Windows. Now I even get this with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20080830020452 Minefield/3.1b1pre ID:20080830020452 Opening the following site and clicking on the dmg image file I get the attachment handler dialog and after clicking on OK, the save as dialog pop-ups and the focus is lost immediately. ftp://ftp.mozilla.org/pub/thunderbird/nightly/2008/02/2008-02-15-03-trunk/
OS: Windows XP → All
Hardware: PC → All
Mmh, with some further tries I could swear that this issue occurs because the helper application dialog closes in the background. When the dialog closes the focus of the save as dialog is lost at the same time. On OS X you have a shortly longer delay which makes this issue more visible. Edward, something you could have a look at?
This isn't a regression, and we don't seem to have a good idea of what's happening, so I can't block the relase on this.
Flags: blocking-firefox3.1? → blocking-firefox3.1-
It is a regression from Firefox 2, so I hope you won't sweep it under the rug because it's challenging to repair.
Related or duplicate: Bug 440186
Related or duplicate: Bug 442218
Related: Bug 442046
Related or duplicate: Bug 436245
Thanks Christian for pointing out to these bugs.
This is really annoying for keyboard navigation and causes all sorts of input errors if you don't look for it.
(In reply to comment #6) > One can either do an event monitor using DOM Inspector, or use the Microsoft > MSAA tools or IBM's accProbe to check the a11y events. They usually correspond > to real events, and from the looks of it, a focus event is fired on some > element on the page *after* the dialog has already opened. Marco, do you have a chance to do that?
This regressed somewhere between FF2.0.0.x and FF3.0. I'll try to get a specific timeframe for that.
Keywords: regression, regressionwindow-wanted
At least on OS X this is a regression which starts between these builds: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050104 Minefield/3.0pre ID:2008050104 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008050204 Minefield/3.0pre ID:2008050204 Checkins: http://tinyurl.com/aepxkf Probably bug 406730 caused this but also bug 428071 could be related. Steven and Markus, can you help us?
Keywords: regressionwindow-wanted
(In reply to comment #23) > Probably bug 406730 caused this I don't think so. > but also bug 428071 could be related. That's more likely. However, that bug only has an effect on Mac OS X, so it's not really what this bug is about. I think it would make more sense to search for the regression range on Windows.
(In reply to comment #23) Is your problem bug 436245? The bug also reproduce on Intel Mac and is resolved as the dup. of this. Should we treat bug 436245 as a diffrent bug from this?
(In reply to comment #25) > Should we treat bug 436245 as a diffrent bug from this? I still don't think so. We should only find the regression range on Windows to better identify whats going on.
Marco, would you have time to check for the regression range on XP?
Keywords: regressionwindow-wanted
this was a tough one ;) i used following STR: - load Fx with http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2008/02/2008-02-15-03-trunk/ - be sure "Options"/"Main"/"Ask me where to save files" is checked - left-click on thunderbird-3.0a1pre.en-US.linux-i686.tar.bz2 - choose open with "xy"; my xy is "7-Zip File Manager (default)" and click on "Ok" - cancel the download - reset focus of Fx by switching to another app and back to Fx - left-click on thunderbird-3.0a1pre.en-US.linux-i686.tar.bz2 - choose "Save to Disk" with left-click works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061105 Minefield/3.0a1 ID:2006110504 fails (file picker does not have focus/title bar is greyed-out): Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061106 Minefield/3.0a1 ID:2006110604 => range: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-11-05+03%3A30&maxdate=2006-11-06+04%3A00&cvsroot=%2Fcvsroot => likely bug 353560 ps. if i'm seeing a different bug as comment 0 please feel free to file a new one :)
Keywords: regressionwindow-wanted
Thanks XtC4UaLL for finding the regression range. Mano, it looks like a regression of bug 353560 which you have fixed a long time ago. Is it something you could have a look at?
Blocks: 353560
(In reply to comment #8) > Mmh, with some further tries I could swear that this issue occurs because the > helper application dialog closes in the background. When the dialog closes the > focus of the save as dialog is lost at the same time. On OS X you have a > shortly longer delay which makes this issue more visible. Edward, something you > could have a look at? I have been experiencing this bug for quite some time myself and I've tried investigating it this night and I think Henrik is right: on my system, I can sometimes see the "Enter name of file to save to" dialog get the focus, but then quickly loses it to the page behind it and it happens when the dialog asking whether or not to save the file closes. I've tested on Firefox 2.0.0.20 and if we pay attention, we can clearly see that while trying to reproduce the problem the dialog on FF2, the save dialog still exists after the "Enter name of the file to save to" has opened and is waiting for it to terminate. In Firefox 3.0, this dialog is closed at the same time the "Enter name of the file to save to" appears. In short: My assumption is that the Save dialog prompt contains code to give the focus back to the page when it closes, and that since Firefox 3.0 it closes itself at the same time as the "Enter name of the file to save to" appears, there is a race condition and the focus goes (most of the time on my system: 85%, but not always) to the page and not to the File Pick ("Enter name of the file to save to") dialog. I assume that making it behave the same way as in FF2 (which is, closing that dialog only after the File Picker dialog has exited itself) would fix this. Any thoughts on this are very welcome since it is a huge annoyance. Thanks.
Attached image Dialogs in FF2 —
Dialogs opened in FF2 when saving a file. The "You have chosen to open" dialog exists until the File Picker dialog has exited.
Attached image Dialogs in FF3 —
Dialogs opened in FF3 when saving a file. The "You have chosen to open" dialog closes at the same time the File Picker dialog opens and as a result the focus goes back to the webpage.
Just attached a couple of screen captures of the behavior in FF2 and FF3 and showing how it differs for further reference to my comment #30. Thanks.
Please also note (see my comments there https://bugzilla.mozilla.org/show_bug.cgi?id=442218) that it isn't just a focus problem: the file picker behavior is completely erratic, for example, double clicking a directory to navigate to it sometimes work, sometimes doesn't, entering a path in the file name box and hitting enter just highlights the whole string in there and doesn't navigate to the directory, entering a file name and hitting enter does the same thing (instead of saving and closing the dialog). Hitting enter many times in a row sometimes makes the dialog close... which indicates some kind of race condition.
I can confirm the same behavior as Frank, which also quite frequently happens for me.
Moving to the correct component.
Component: Disability Access → File Handling
QA Contact: disability.access → file.handling
Summary: After opening File Save As dialog, a focus event back to the web page gets fired → File Save As dialog opened via unknown content dialog, a focus event back to the web page gets fired
It would be really nice to get it fixed for 3.6.
Flags: blocking-firefox3.6?
If my report was a duplicate and has been fixed why is it that the bug is still there?? Why are ppl taking this action when cleary its not fixed
I agree. This bug still is present in 3.5.0 and 3.5.1 and is very annoying. It has been there for a very long time since 3.0. I think that usability issues are as important as javascript speeds and that some Firefox experts should take some time to work on this one please. Thank you.
This bug is not fixed yet. See the status of this bug. That means we don't need any more confirmations that the bug still exists. We know that and a developer has to take care of this bug. Anyone can step in here.
Not blocking, but we'd take a patch. David/Marco, are you looking at this for Firefox 3.6? I've cc'd Neil Deakin who might have some ideas.
Flags: wanted-firefox3.6+
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.6-
This hasn't been on my radar at all. I'll wait for Neil's thoughts.
I'm encountering this on a daily basis, almost everytime I save a file via download.
I have noticed something. If I am on sourceforge.net downloading files as a regular internet user (https://sourceforge.net/projects/mingw/files/), and I right click on a few and pick open in new tab, I should get several download dialogs, right? I do. but the download dialogs atppear in rapid succession. when this happens, only 1 of them gets the focus. the one that gets the focus first is the one that has the save button enabled. all the rest have their save buttons disabled. this is SOooo wrong... what kind of modal did you choose for the resources in this dialog anyway, that you can have only 1 focus for the entire application? and why is the focus on those other dialogs on the radio buttons and not on the save button? please fix yesterday!
Parent was being set to the content window instead of the top chrome window.
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Attachment #410837 - Flags: review?(sdwilsh)
Don't think this can be tested automatically as it involves opening the native file picker.
Attachment #410837 - Flags: review?(sdwilsh)
Comment on attachment 410837 [details] [diff] [review] use the toplevel window instead Bah, I just tried this again and it didn't work!
Not to state the obvious but the behaviour still is the same in FF3.6. Not to rant or anything, but this is a major usability issue and I wonder if the Firefox managers realized how annoying it is and painful to deal with everyday in real-life... What I mean is, I don't really care if JavaScript processing goes 0.5% faster if I'm wasting the time benefit hundred fold by looking where the Save file dialog went... and I'm sure I'm not the only one. I'm considering going back to IE or Chrome: yeah, it is that annoying! Thanks for taking the time to seriously consider fixing this bug.
Neil, you are assigned to this bug. Will you have time for fixing it or shall be hand it back to the base?
blocking2.0: --- → ?
I've spent much time on it in the past but couldn't determine a suitable fix. The issue if I recall is that the unknown content dialog is being closed on a timer which fires while the file dialog is being opened.
Now that Neil Deakin has tried to fix it but couldn't determine a suitable fix, what is going to happen now? The bug still is assigned to him but I doubt he is going to try it again as he has already tried to fix it? Maybe it is time to consider assigning the bug to someone else and/or to more developers able to fix this case. Thanks!
(In reply to comment #52) > So we are talking about the following function, right? > > http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/downloads/nsHelperAppDlg.js#167 Neil, can you just give a ACK? Reassigning to default so others can take a look at.
Assignee: enndeakin → nobody
Status: ASSIGNED → NEW
That's the right place to start investigating. It's where the file dialog is opened. But I can't seem to reproduce this bug anymore, at least on Windows 7. I think what was happening is that the dialog was being opened, at the line that calls picker.show(). Before the file dialog opens, a timer fires and closes the other unknown content dialog. The file dialog opens, but because the other dialog was closed, focus shifts to its parent.
It's still there with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a3pre) Gecko/20100305 Minefield/3.7a3pre ID:20100305031050 steps: 1. select to ask for the download folder 2. open http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/11/2009-11-01-04-mozilla-1.9.2/ 3. tab to the mar file 4. press return 5. press return again (save button) Those steps let the focus constantly go back.
While not ideal, this isn't a regression so I can't really justifying us blocking the release on it.
blocking2.0: ? → -
(In reply to comment #57) > While not ideal, this isn't a regression so I can't really justifying us > blocking the release on it. I agree, but this bug has been here since more than two years and the feeling it gives is that no one is looking at it... Is it possible to have this bug seriously assigned by someone, preferably the one who wrote this code, if he is still around? Thanks.
I just posted on Bug 610256 on this issue, before finding this bug; it seems to be far better detailed here. Anyway, confirming this for: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b13pre) Gecko/20110316 Firefox/4.0b13pre Focus is sometimes randomly returned to the browser window from the file select dialog, without any consistency. Expected behavior is that file select dialog always receives focus. Sorry for bumping an old bug, but this was driving me nuts tonight, hoping that someone can finally pin it down and check it off the list of bugs; Thanks!
Still happening on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0 *twitch*
Still Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6.8; rv:5.0.1) Gecko/20100101 Firefox/5.0.1 I don't remember to have the problem on my home PC (Win 7), so probably Mac only?
This bug is annoying me (and some of my customers) since 3 years now and now it's also occurring in Thunderbird 6.0. When I double-click on an attachment in TB 6, the same "Opening ..." dialog occurs as in FF. When I select "Save File" the "Save as" dialog is sometimes in the background.
Seemed to have been fixed in last several nightlies. Looks like this is a reversion of some kind >_<
(In reply to RC from comment #64) > Seemed to have been fixed in last several nightlies. Looks like this is a > reversion of some kind >_< mark as worksforme?
(In reply to RC from comment #64) > Seemed to have been fixed in last several nightlies. Looks like this is a > reversion of some kind >_< can you identify which date of nightly fixed this?
This is not fixed. It's still there with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0a1) Gecko/20110929 Firefox/10.0a1
Switching to use filepicker's open() instead of the now obsolete show() in nsHelperAppDlg.js should fix this.
(In reply to Stefan [:stefanh] from comment #68) > Switching to use filepicker's open() instead of the now obsolete show() in > nsHelperAppDlg.js should fix this. So...has anyone confirmed that this solves the problem? Given the long history of this bug (and associated duplicates), if a solution as straightforward as the above really works, seems like an open-and-shut case. Any takers? (I'd do it myself if I were a programmer, but alas, I am not.)
hmm. in 19.0 one annoying thing is the OK button gets grayed out as long as the dialog doesn't have the focus. so now it requires *3* clicks instead of 2 to click on an OK button, one to click on the dialog title bar, and one to click on the OK button to save and then another to actually save. I think I should be able to rapidly do 2 at most without the focus-click. at least cancel is there. I don't know why OK is being singled out. the way things are now it just makes my job harder.
Bug is still present in Firefox 21 on both OS X Lion (10.7.5) and Mountain Lion (10.8.4).
Tested here with Ubuntu 12.04 (precise) and Mozilla FF 27.0.1 Using the Dialog from File -> Save as = Everything is fine. Using "right-click" on a downloadable link -> "Save Link as" = the Name field has no focus but the extension field has. (.mpeg) So I have to click into the name field first bevore adding a name. But now I noticed if I changed focus before manually to the name field by clicking into it - but then cancel the action and rightclick again and chose "save link as" again => then the name field directly got focus. I then tried it on another website. And still now I had focus in the name field again. I have to check how it will look like if I restart my system. But this can take a while cuz I cannot restart right now.
(In reply to Frank from comment #34) > Please also note (see my comments there > https://bugzilla.mozilla.org/show_bug.cgi?id=442218) same issue is also present in FF 31.3.0 ESR under Windows 7 Ultimate x64 SP1
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 8 duplicates and 11 votes.
:Gijs, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(gijskruitbosch+bugs)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(gijskruitbosch+bugs)

I tried to reproduce this bug on Windows 11 with Firefox 112.0.2 (64-bit), i.e. by downloading EXE files from https://ftp.mozilla.org/pub (per the comment #56), and I was not able to reproduce the issue.

Note, only when Save Link As... option is activated from a context menu (Shift + F10) the Firefox on Win would show a save file dialog. But replacing the file with the same name download is still working with a keyboard as expected.

On Mac with macOS Ventura 13.3.1 with Firefox Nightly 114.0a1 (64-bit) downloading itself works as expected, but if you want to save a file with the same name, a standard macOS dialog is opened on top of the Enter name of file to save to... save file dialog and there neither Replace not Cancel buttons can be activated with an Enter key, only a Space can do (the screenshot of this dialog attached). But this appears to be an OS issue, because both Safari and Chrome experience the same issue.

No focus issues were observed.

@Gijs, maybe this bug could finally be retired with WorksForMe?

Flags: needinfo?(gijskruitbosch+bugs)

(In reply to Anna Yeddi [:ayeddi] ❌ On leave till May 7 ❌ from comment #78)

Note, only when Save Link As... option is activated from a context menu (Shift + F10) the Firefox on Win would show a save file dialog. But replacing the file with the same name download is still working with a keyboard as expected.

You can configure how Firefox handles downloads in the settings/preferences, and if you set it to "always ask me where to save files" then you can get a save file dialog every time. If you also set it to "always ask me what to do with downlaods", you will first get a different dialog (the "unknown content" dialog referenced in this bug's summary).

I think someone would need to use these settings and then check for the focus event described in the bug, before deciding whether the bug can be closed WFM.

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(ayeddi)
Flags: needinfo?(ayeddi)

I re-tested on Windows, I think this is wfm. We can reopen if people still see this and have more detailed steps to reproduce.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: