Closed Bug 465511 Opened 16 years ago Closed 1 year ago

Save As dialog: pressing ENTER doesn't always work

Categories

(Core :: Widget: Win32, defect, P3)

Product:
Core
Component:
Widget: Win32
Version:
1.9.0 Branch
Platform:
All
Windows
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox122 --- fixed

People

(Reporter: doron.feldman, Assigned: rkraesig)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 Sometimes, when pressing the ENTER key in the Save As dialog, nothing happens. Reproducible: Always Steps to Reproduce: 1. Browse any web page or image 2. Save As... or Save Image As... 3. press ENTER Actual Results: Sometimes: nothing happens Expected Results: Dialog should close and file saved. If the file name in the File Name combo box was not highlighted (e.g., after editing the name), after pressing ENTER it becomes highlighted. The bug only happens about 50% of the times I press ENTER. In other times the dialog closes and the file is saved as expected. Sometimes it is necessary to press ENTER several times before the file is saved, which makes this bug rather annoying. The bug does not happen when clicking on the Save button with the mouse pointer.
Version: unspecified → 3.0 Branch
I face the same problem since a long time ago, enough time to not remember since which version I find this behavior. Right now, I'm using latest build of Windows 7 with the same profile data as before (XP SP2). This is the only thing that has changed, and the problem goes on, but in fact, much worse: now, about 90% of the saving tries, ENTER will not work. Even worse: sometimes ALT+S won't work too (it saved me most of the times), I just HAVE to use the mouse and click on the Save button.
Sorry, forgot to add: using Fx v3.5.3 right now.
This bug is very annoying and I've wondered a long time why it's still there in such an everyday functionality as saving images and pages. The bug is there also if you try to save an image with the same name once again: The "Confirm Save As" dialogue pops up with its "Do you want to replace it?", and the "No" button is marked as default - but it doesn't always react on the Enter/Return key. This gives a good method of testing how often ENTER works: 1. Right-click on an image and save it as its original filename. 2. Right-click on it again. 3. Now press ENTER repeatedly. This will alternate between the Save Image file selector and the Confirm Save As dialogue, but occasional unresponsiveness of the ENTER key delays the alternation. Oh! Now I see that the ESCAPE key seems to have the same glitchy behaviour as ENTER. What can cause this error on ENTER and ESCAPE but not the alphabet keys etc?
Reporter, are you still seeing this issue with Firefox 3.6.10 or later in safe mode? If not, please close. These links can help you in your testing. http://support.mozilla.com/kb/Safe+Mode http://support.mozilla.com/kb/Managing+profiles
Whiteboard: [CLOSEME 2010-11-15]
Seems to be working properly now (3.6.10)
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Resolution: FIXED → WORKSFORME
Also tested it several times, and it seems it has been fixed. At least, in Windows 7 (sorry, that's the only one I'm using right now), it's working as expected.
I haven't seen this problem since some versions back, but now I suddenly encountered it with version 3.6.12 when saving a number of mp3 podcasts from this page: http://sverigesradio.se/sida/poddradio.aspx?programid=2332&pid=2960 Pressing ENTER doesn't work while another download is still in progress, but when no other file is downloading it responds directly as it should. (Has this fact been observed before?) Pressing the Save button DOES work, which gives me the impression that it's not just the server denying my download.
i wanted to add, that this bug is still happening on firefox 23.0.1. either it resurfaced, or wasn't actually fixed but the other reporters just were lucky/unlucky enough to avoid it while testing.
This bug did not resurface, it persisted ever since version 3. I am quite astonished that it hasn't been fixed since then. I have fond memories from those days.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
This bug is fixed since then time(2008!), good to close.
If you can reproduce this in Fx25, let us know :) Cheers!
Flags: needinfo?(doron.feldman)
It is most certainly not fixed since 2008, it has persisted ever since v. 3.0. It still occurs in v. 24.0. I am not planning on installing a beta version so I can't report about v. 25. By the way, for what it's worth, I did notice that it happens more frequently when larger (or slower) downloads are involved.
Flags: needinfo?(doron.feldman)
Whiteboard: [CLOSEME 2010-11-15]
still happening in ff 25.
I have the newest version (26) and I can reproduce this without fail at times (no matter how many times I try, pressing enter does nothing short of highlighting the name of the file I'm trying to save). I'm using Windows 7. This is excruciatingly annoying when using a slow mouse / no mouse at all and trying to download many files in a row.
I'm still able to reproduce this bug using v29.0.1 on Windows 7.
I also encounter this bug often, currently using v29.0.1 on Windows Vista.
Still happening with v31. This bug has been present over different computers and different operating systems for me.
It seems like this only happens when firefox is busy loading other pages, and it also affects other keys.
I also know this bug since almost ever... I really can't believe it has not yet been fixed. It still exists in version 37.0.1. To reproduce it, start a download while another download is in progress and immediately press enter repeatedly. You will hopefully notice, that the first enter key stroke won't close the dialog. This does not only affect the Firefox download dialog (where you can choose to download or open the file), but also the "Save as" dialog where you choose the download location. I just tried it by download Ubuntu from here: http://wiki.ubuntuusers.de/Downloads/Trusty_Tahr
37.0.2 on XP SP3 WTF?
I have this bug on Windows 7 SP1, didn't see that this bug was reported for XP...
It still happens often, even if there are no downloads pending. I'm using Windows 7 Home Premium, and Firefox 38.0.5. I have a lot of tabs open, if that matters.
Component: General → Widget: Win32
Keywords: steps-wanted
Product: Firefox → Core
Version: 3.0 Branch → 1.9.0 Branch
This bug is the most annoying and problematic thing in the entire Firefox for me and probably for anyone who saves images at least from time to time, and should definitely be given much attention. It is happening when saving images at least in Windows 8 and Windows 10 x86 and x64. I’d say, the Enter key does not work the first time in about 15% of cases. It is absolutely reproducible – I have installed Windows 10 x86 on VirtualBox, didn’t install anything else other than support drivers for VirtualBox and Firefox 47 release, and started saving photos via right-click - Save image as… , with renaming them. The bug will manifest itself, not often, but it will. It might be worth noting that in Chrome the Save dialog looks completely the same, the only thing that differs is what’s in “Save as type” field: In Firefox it is “ACDSee 18 JPEG image (*.jpg)” In Chrome it is “JPEG Image” BUT this bug DOES NOT HAPPEN IN CHROME! So maybe just copying from Chromium some part of code that’s responsible for this thing, will help? Please, look into it, it’s a very annoying bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This may sound silly, but my current thought on this is that a straightforward code sequence cannot make this happen. In this, and I think a few other little bugs, Firefox seems to be making something that's really being handled by a windows routine mess up. So some asynchronous thing or background-work-process thing seems to be interfering with Windows' processing of a key press (Enter being hit). The naïve user thinks that Firefox is handling the clicking, typing, and hitting of Enter in the pop-up window, rather than prepping the window contents with windowing calls then calling a windowing routine to handle all the input, and so thinks that your code is straightforwardly mis-handling the hitting of Enter. That's why so many people think this should be such an easy bug to fix. Does this make sense?
As a programmer for move than twenty years I've had more than my share of dealing with Windows GUI idiosyncrasies. They can be tricky at times but there's always a solution. I also know that it is impossible to get a bug fixed if nobody is even trying. I have a seven year old daughter who wasn't even born when the Save button in Firefox worked properly. (In reply to mwrenton from comment #30)
Flags: needinfo?(twalker)
Priority: -- → P2
Whiteboard: tpi:+
This works for me on Win 7 with latest Nightly 51.0a1, 20160821030226. ctrl-s then Enter, saves the page just fine. I understand for those seeing this, it is frustrating. Are you using any accessibility tools? What about system settings for keyboard access, have you changed any related setting? If any of those are in play we need to know for better steps to reproduce.
Flags: needinfo?(twalker)
Priority: P2 → P3
I reported the duplicate bug 1143462: I don't use any accessibility tools. I prefer to use at less installed applications as necessary ;-) With Firefox 47.0.1 and 48.0.1 I was not able to recreate the problem for now. Probably it was fixed in meantime. Maybe somebody else is still able to reproduce the problem?
Sorry, still happens in both 47.0.1 and 48.0.1. Not using any accessibility features. Usually happens with large files, especially when several files are being downloaded at the same time.
I see this problem in Fx48.0 with clean profile on Win10 14393 (1607) x64. It has occurred mainly in the files be being downloads, not interrelated with large files. I also can occasionally reproduce it in 51.0a1 (2016-08-22) e10s on.
Happens to me on Win7 SP1 64bit and Win10 64bit (1607), Firefox 50.0.2. Save as -dialog sometimes requires multiple Enter key presses before it accepts it. No accessibility features enabled.
I think this is a Windows bug, not a FF bug. I had it in Windows 7 x64 and now in Windows 10 x64. I have it with many apps including photoshop, foxit, Office apps, etc. etc. Sometimes when I edit a file name and then press ENTER, the new file name will be highlighted in blue but the file is not saved. Sometimes I cannot load a file previously saved. If I select the file name from the list at the top of the Open File dialog, it will appear in the target file box down below, but then I press enter, nothing happens. If I double-click the file name in the list, it will then open. I was looking for a solution and came across this thread, am hoping this info will be helpful in finally resolving the issue.
OS: Windows XP → Windows
Hardware: x86 → All
Is reproducible in Windows 7 x64 (60.4.0esr (32-bit). In order to reproduce it, you need to have many files in the target folder, for me it reproduces when you're saving the file or image, and you just need to press Enter for a few times until it is accepted. However, pressing the 'Save' button by mouse closes the save dialog immediately.

It seems, Chrome creates a separate process every time for "Save image as" window - it can be easily seen in Windows Task manager and in Chrome's internal task manager. Firefox does not. Chrome does not have this bug. Firefox does. So, maybe if Firefox developers put "Save image as" window into a separate process, it will fix this HORRIBLE bug. Fix this ASAP, please!

Also, I'm not sure but it seems, Enter key does not work (for the first time it is pressed) only in cases when user starts typing a new file name IMMEDIATELY after choosing "Save image as" in image's context menu, while that window is still being painted/animated, possibly only when folder already contains other images that start with the same letters and thus autocomplete list appears briefly while entering new name.

Also, maybe this bug is related to bugs like this one https://bugzilla.mozilla.org/show_bug.cgi?id=431544 (there are several other bugs about “save as” dialog as well)

Or, if you think that it is Windows’s fault, maybe file a bug to Microsoft? But quick google search shows that ONLY FIREFOX has this bug. Firefox is the first and pretty much the only relevant result.

Other erratic behaviors, including this bug, are listed here https://bugzilla.mozilla.org/show_bug.cgi?id=442218

Note that bug https://bugzilla.mozilla.org/show_bug.cgi?id=431544 , judging from its description, is ALWAYS reproducible, and it supports my observation that something that makes Enter not work (a focus event back to the web page) happens a short time after opening “Save as” dialog. So, now you have a way to debug this, and therefore, a way to fix this.

A couple of excerpts from bug https://bugzilla.mozilla.org/show_bug.cgi?id=442218 :

“This window will be out of focus so the keyboard can't be used to navigate in it but there's worse: ALT-TAB wont bring you to it but bring another application in focus instead of firefox, so only using ALT-TAB twice will finally bring you inside that window.”
<…>
“Hit [ENTER]: Normally, this should confirm the file name, close the dialog, and save the file. More often than not, [ENTER] will only rehighlight the whole text in the "file name" entry box. You have to hit [ENTER] a number of random times to finally make the dialog box go away.”

The last paragraph describes exactly the behavior of this bug, therefore I conclude that the cause of this bug definitely is a temporary loss of focus of ”Save as” window during its opening.

And after further testing, right now, on Windows 10, I'm pretty sure that this temporary loss of focus of ”Save as” window during its opening is happening ONLY WHEN user starts typing a new VERY SHORT (like "01", "02", "03" - no more than two letters) file name IMMEDIATELY (with very little time passed) after choosing "Save image as" in image's context menu and presses Enter IMMEDIATELY AFTER THAT.

If user inputs new file name immediately after choosing "Save image as" in image's context menu, BUT WAITS before pressing Enter, bug does not manifest itself. So pressing Enter early is key for making "Save as" window lose focus temporarily.

The above is 100% consistently repeatable for me. Chrome and Photoshop do not have this bug at all, no matter how quickly I enter new file name and press Enter.

After even further testing, I think it became even more clear what's going on:
For approximately two seconds (I guess it depends on how fast user's PC is, mine is old) after clicking "Save image as" in context menu, Firefox's main window border is still colored, which means it's still active. Save as dialog is being painted. But in spite of that, letter presses are already being cached for input in file name field which is not yet drawn on screen. Enter key is also probably being cached, not as a command to "Save as" window's "Save" button, but as an indication that file name entry is completed, that's why new file name is selected when "Save as" window is finally drawn.

If Enter key is not pressed during these two seconds, new file name is not selected.

If Enter key is pressed after Firefox's main window border becomes desaturated (by that time, "Save as" window is already fully drawn on screen and is active), Enter key works as it should - it saves the file.

Disabling windows animations in System properties control panel does not speed up things.

The visual difference between Chrome and Firefox seems to be that
Chrome: 1) loses focus of main window 2) paints "Save image as" window 2) gains focus on "Save as" window
Firefox 1) paints "Save image as" window 2) waits a little after that 3) loses focus of main window 4) gains focus on "Save image as" window

After even further testing I found out that RARELY (maybe once in 20 pictures saved) Enter key does not work even when it is pressed much later after opening "Save as" dialog (and entering new file name). But I hope I brought something new to think about, this bug seems to have something to do with loss of focus on "Save as" dialog. I wasn't able to reproduce bug https://bugzilla.mozilla.org/show_bug.cgi?id=431544 (though I wasn't trying hard and I didn't use screen reader or debugging tools), but it has never really been fixed, so maybe somewhere there lies an answer, or in the piece of code where "Save as" dialog is initialized and called (compare to Chrome's sequence of events), or creating a separate process for "Save as" dialog is the solution, like in Chrome.

Also, I used high-speed camera on my phone and I saw that for a brief moment in time (several frames on 60 Hz display, actually) on Firefox both "Save as" dialog and main Firefox window have focus at the same time (a second after choosing "Save image as" in image's context menu, while "Save as" dialog window is already on screen, its contents being painted). I saw that on Chrome and Notepad that doesn't happen. Maybe this should not be happening, maybe this is a race condition? Or maybe this is not a good way to judge transition of focus.

(This can be better seen when windows animations are disabled in Control panel)

Dmitriy, I don't know if the problem you are describing is related to this one. This bug happens when the "Save As" dialog is definitely in focus. You can even type in a new file name. When pressing ENTER, the dialog responds. The problem is that the response is not always the correct response. Instead of closing the window and saving the file, sometimes the response is rather to select the file name in the edit box (if it isn't already selected) and keep the dialog open. This can sometimes happens even after pressing ENTER multiple times.

This is still happening in Firefox version 89.0 . The last version before this bug appeared was Firefox version 2.0 . My 12 year old daughter wasn't even born yet.

Yes, this is exactly the same bug I’m describing. What I did yesterday is I found a way to kind of reproduce it every time (instead of sometimes): if user inputs new short file name immediately after selecting “save image as” and then immediately presses Enter, it leads to selecting the file name in the edit box and keeps the dialog open, and sometimes (rarely) even multiple presses of Enter don’t close the dialog. And in comment 50 I found out that sometimes this bug is still happening even if user inputs file name when waiting longer than two second (the same way it was happening before, when I reported this bug 5 years ago in comment 24). In these first two seconds (when bug is guaranteed to happen) the focus is still on main Firefox window, so that means this bug is happening because periodically “Save as” dialog loses focus (also see comment 46 - it describes a bug when focus is lost from that dialog and user has to alt+tab back to it, with exactly the same symptoms as this bug). I attempted to give programmers a better idea of what’s going on, because they sort of indicated in comment 30 that they don’t know what to do. And Chrome’s spawning a new process just for that dialog is important, I think. A potential solution.

And bug in comment 45 (it’s a different bug of course) has tools listed (screen reader, process debugger) that are worth trying to see if my assumption about periodical loss of focus is correct.

So, it of course looks visually that focus is on “Save as” dialog all the time, but is it really? Maybe at times it isn’t (100% repeatability of this bug’s symptoms in the first two seconds when focus is still on main window indicates so), and key presses are buffered, then inserted as string when focus is back to “Save as” dialog? And Enter inserted as part of string from buffer is interpreted as “end of line” symbol instead of command to save file?

If the dialog responds to ENTER, how can it not be in focus? Note that it responds to all keys correctly, except the ENTER key. I really don't see how this could be a focus issue.

Well, maybe I’m wrong, I’m just speculating, attempting to get things moving with this bug somehow. “Save as” dialog doesn’t exist during the first two seconds after selecting command in context menu. Input field for file name doesn’t exist yet. Main window is still in focus. Yet when “Save as” window finally appears, all the keys pressed when it didn’t exist get entered in file name field. So it looks like they are buffered.

And “Save” button in “Save as” dialog doesn’t exist as well during the first two seconds, that might be why Enter key is not functionally tied to it during this time when “Save” button doesn’t exist OR exists but not in a window that is in focus when Enter key is pressed. Just guessing.

https://www.ibm.com/docs/en/host-on-demand/12.0?topic=SSS9FA_12.0.0/com.ibm.hod.doc/help/keybuffer.html
“Keystroke buffering, also referred to as type-ahead support, enables you to enter keystrokes in an emulator session even when input is inhibited. Keystrokes are buffered when input is inhibited and processed later when the input-inhibited condition is removed.”

https://community.progress.com/s/article/17748
“ What is the type-ahead keyboard buffer maximum on Windows?”
“The keyboard type-ahead buffer can contain a maximum of 16 characters.”

We are not the only ones suffering from this bug:
https://superuser.com/questions/890736/disabled-enter-key-in-save-image-dialog-sometimes-in-firefox
https://superuser.com/questions/1184923/firefox-save-file-dialog-requires-multiple-enter-key-presses-how-do-i-disable-t
These are top results in Google search request “enter key selects file name in save dialog”. No other program has this bug. Rewrite the code responsible for saving completely if you can’t figure out where the problem is, please. Page rendering improvements and conformance to new web standards will not stop users leaving Firefox if Firefox fails at basic things for decades. Try saving a gallery of 50 images with renaming them sequentially to “01”, “02”, “03” (for preserving original order when sorting in folder), and you’ll feel HUGE PAIN because of non-working Enter button.

Also, I used AccEvent debugging tool as suggested in https://bugzilla.mozilla.org/show_bug.cgi?id=431544 and the only thing different between image saved with Enter key bug and without the bug appears to be the order of events probably fired at creation of interface elements of Save as dialog. When I pressed Enter and it selected file name instead of closing the dialog, no event fired at all. Total number of logged events is exactly the same in both buggy and non-buggy run.

Also, I ensured that blue outline that represents focus on UI element, is present in the dialog both on file name field and Save image button, in both buggy and non-buggy cases. So, no difference there.

The bug exists in Windows 11 as well, easily reproducible in VMware Workstation (which means it's hardware agnostic). In the 4th image that I was saving with renaming, pressing Enter selected file name. So we're stuck with it for a very very long time if Firefox developers won't fix it. https://imgur.com/a/9AtmIO8

I've been struggling with this problem for at least 7 years through all the Firefox versions (then and now), the problem seems to be that when you have a web page open and click on a download link, Firefox calls the "Save As" or "Save File" Windows common control and that in many instances the user can see that the "Save" button is highlighted (meaning it's the default button in the dialog) and you can press the "Enter" key or alternately the "Alt-S" shortcut and the dialog fails to respond to either of these keys. As many people have indicated, with the dialog open you can press "Enter" or "Alt-S" ten or twenty times and it fails to respond and the only way to continue is to use the mouse to actually click the "Save" button which always works. I have noticed that in many instances if you've hit "Enter" 10 or more times and then try "Alt-S" or vice versa maybe one out of five times that works for some reason. The thing that I have to wonder is if the bug is not in Firefox but in the Windows Common Control save file dialog.

Still not solved after 15 years. I still have to hit enter multiple times until finally accepts and saves the file. This happens more often if one of your downloads is an .exe file or your are saving in a folder with some .exe files (like GOG offline installer downloads), but it also happens with "normal" folders.
Persistent from Windows Vista up to Windows 11 (with all in-between), and from Server 2008 to Server 2022.

Severity: normal → S3
Whiteboard: tpi:+

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(spohl.mozilla.bugs)
Severity: S3 → S2
Flags: needinfo?(spohl.mozilla.bugs)

(In reply to Chris LeFebvre from comment #64)

I've been struggling with this problem for at least 7 years through all the Firefox versions (then and now), the problem seems to be that when you have a web page open and click on a download link, Firefox calls the "Save As" or "Save File" Windows common control and that in many instances the user can see that the "Save" button is highlighted (meaning it's the default button in the dialog) and you can press the "Enter" key or alternately the "Alt-S" shortcut and the dialog fails to respond to either of these keys. As many people have indicated, with the dialog open you can press "Enter" or "Alt-S" ten or twenty times and it fails to respond and the only way to continue is to use the mouse to actually click the "Save" button which always works. I have noticed that in many instances if you've hit "Enter" 10 or more times and then try "Alt-S" or vice versa maybe one out of five times that works for some reason. The thing that I have to wonder is if the bug is not in Firefox but in the Windows Common Control save file dialog.

On Windows 11 with the release of Firefox 112.0.2 (64-bit), I tried to reproduce the bug multiple times, saving EXE files from https://ftp.mozilla.org/pub and 4.9+ Gb files from the https:// wiki.ubuntuusers.de as well as saving multiple images (i.e. the one posted in the comment 63 - https://imgur.com/a/9AtmIO8), by pressing ctrl + S to save the entire page with an image, pressing shift + F10 to open context menu > Save Link As..., then by renaming the file quickly or slowly, by leaving the filename the same and prompting to overwrite it, by saving it in the different folders, by pressing Enter and Alt + S with the file name selected or not, with NVDA screen reader running and without any assistive technology - neither of these reproduced the bug for me.

The only one time the behavior of the dialog was not behaving purely as expected was in the case of quickly renaming an image to a one letter-long reused title (s in this case) and pressing Enter: in this case, the sound of a dialog to overwrite the file (Confirm Save As) was played and the dialog did not appear visually before I quickly pressed Enter again (activating No button of the confirmation dialog). The focus was returned to the Enter name of file to save to... save file dialog, as expected.

Maybe a new set of clear steps to reproduce with a specific URL(s) used would help to reproduce and investigate this bug, if it still exists.

Still Happening. For example, I started downloading the .exe files in random subdirectories under https://ftp.mozilla.org/pub/firefox/releases/100.0b1/win64/ and almost every file I selected required one or two extra "Enter" hits.

Running on 112.0.2 (64-bit) Windows 10 Pro

(In reply to Dozza from comment #69)

Still Happening. For example, I started downloading the .exe files in random subdirectories under https://ftp.mozilla.org/pub/firefox/releases/100.0b1/win64/ and almost every file I selected required one or two extra "Enter" hits.

Running on 112.0.2 (64-bit) Windows 10 Pro

I have been able to very intermittently (much less than 1/4 of the time) reproduce this on the same version. So far I have only seen it with the .exe files; I have been unable to repro using the .msi files located alongside them. @Dozza, is that also true for you?

Flags: needinfo?(doron.feldman)

Strike that; not 30 seconds later I had it happen with an .msi file.

(It's perhaps also worth noting that I don't experience this in daily use -- I don't think I've ever seen it happen outside of this test case. Which is odd, since there doesn't seem to be anything particularly unusual about it.)

Flags: needinfo?(doron.feldman)

I just had this bug start happening to me only within the last few days. At first I thought it was a Windows 10 issue since I had recently made some registry changes to disable the A.I. that Microsoft recently added to Office. But I've been able to save images using the Enter key in other apps, so I did a test. I tried saving using Save Image As in Firefox to see if the issue was intermittent (it's not). I then opened Edge and did a Save Image As using the same website, image, and destination folder. No issues. Before I ran this test I had already used the Windows DISM tools to scan and fix system issues, used CCleaner to delete all garbage and fix registry issues, closed all open tabs (I had ~160), and restarted my computer multiple times. Therefore, I feel pretty confident in saying that this is solely a Firefox issue.

Since I am seeing this for more than ten years now and some here still say "cannot reproduce" I decided to record a nice little video on how annoying this is: https://youtu.be/Xp3pnMKQx6E
I am using Carnac to show my key presses so you can literally see what I am doing. Have fun watching! I cut it down to make it short and spare you the blah blah, I hate overly long videos with unnecessary blah blah blah. Bug first appearance at about 0:55, and today the record on "how many times I have to press enter" is seven, recorded in that video.
It does not only happen in Firefox, it happens in Seamonkey as well and in Waterfox and probably all other Mozilla-Engine based browsers. One of those many never-fixed-bugs which drives users away.
OS: From Windows 7, 8.0, 8.1, nearly all Win10 versions and Windows 11 now - this Firefox problem never went away. Hardware ranging from i7-2500k/i7-4960x/Ryzen 2700x/Ryzen 3900x/Ryzen 5950x (I spare you the older machines down to AMD 80286..). The Ryzen CPUs got ECC memory from me, the previous CPUs obviously not.

This is still a problem in 2023. For this problem, it seems to happen as long as the url shows in the status bar. Mouse over a link, URL appears, click save as, save dialog pops up. If the URL is still disappearing, Save button does not work. If it takes long enough for the Save dialog to populate, the URL fades away.

I suspect the problem is Firefox eating window messages while the URL fades, but I haven't experimented further. Being patient and letting the URL go away results in 100% success rate. Being quick on the ENTER key is basically a race condition.

Testing suggests this may be fixed after bug 1837079 lands.

Depends on: 1837079

(In reply to Dan Mitt from comment #75)

This is still a problem in 2023. For this problem, it seems to happen as long as the url shows in the status bar. Mouse over a link, URL appears, click save as, save dialog pops up. If the URL is still disappearing, Save button does not work. If it takes long enough for the Save dialog to populate, the URL fades away.

I suspect the problem is Firefox eating window messages while the URL fades, but I haven't experimented further. Being patient and letting the URL go away results in 100% success rate. Being quick on the ENTER key is basically a race condition.

The bad news is that I can confirm it's not this. When running in a build of Firefox with debug instrumentation, the URL disappears in only slightly more than the usual amount of time, but the Save button may not start responding to the Enter key until several seconds later. (And of course the debug instrumentation doesn't seem to show anything that lines up with Enter-key presses, or else this would be much easier to fix.)

The good news is that, as :gcp's implied above...

(In reply to Dmitriy from comment #42)

It seems, Chrome creates a separate process every time for "Save image as" window - it can be easily seen in Windows Task manager and in Chrome's internal task manager. Firefox does not. Chrome does not have this bug. Firefox does. So, maybe if Firefox developers put "Save image as" window into a separate process, it will fix this HORRIBLE bug. Fix this ASAP, please!

... I've been working on doing exactly this, and it does seem to fix it, or at least work around it. Even in the dog-slow debug build, an out-of-process file picker responds to the first press of Enter.

Note that bug 1837079 won't fix it immediately: the current plan is to leave it disabled in Release builds for a time while we gather stability and performance data in Firefox Nightly. If you're fine with running technically-experimental code, though, you'll be able to set a pref to turn it on anyway.

Assigning to :rkraesig based on the OOP file picker work that may influence the severity of this bug.

Assignee: nobody → rkraesig

I'm assuming this is related - when saving an image, and a file by that name exists, most of the time focus returns to the filename for a quick edit.

Sometimes it does not.

I'll try nightly for a bit. It's rare, and I don't save that many images, so it will be hard to tell if it is fixed. If not I'll do a separate bug that that. But it does suggest that windows messages like WM_FOCUS are being eaten or misdirected somewhere.

Good news, everyone!

The patch for bug 1858225 — which merely moves the file-picker to a different thread, rather than a different process — also appears to fix this.
I've tested it in a local debug build with no optimizations (which reproduced the bug more consistently), and not seen it; and likewise for the current Nightly build.

The async part will ride the trains immediately, rather than waiting on further analysis, so it'll go out for sure in v122. (The out-of-process file-picker may be delayed until v123.)

Closing as RESOLVED FIXED.

Status: NEW → RESOLVED
Closed: 15 years ago → 1 year ago
Resolution: --- → FIXED
Duplicate of this bug: 441984
Depends on: 1858225
You need to log in before you can comment on or make changes to this bug.