2047865 - GTK file picker doesn't have Open/Save as default action in Firefox 152.0 (enter key doesn't work, no warning when overwriting duplicate files)

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[shibotto]

Steps to reproduce:

1. Disable the portal file picker
2. Enable asking where to save files every time
3. Press Ctrl+s to save the current page
4. Press Enter while focusing the filename text entry

Actual results:

Nothing happens, as save is not the default action anymore. I need to click the save button or tab to focus it.

Expected results:

Save the file with the inputted filename. This is especially bothersome when trying to download many files one after another.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

Yes, it was decided to remove the default action to make sure the 'accept' is not selected accidentally.

Comment 3

[shibotto]

Can I make it the default action again on my end, maybe using a key in about:config? The portal implementation doesn't seem to be affected by this change, but it often starts unfocused which is bothersome in its own way and the reason why I disabled it in the first place.

Comment 4

[Dominique Kaiser]

(1)
The new behavior is more misleading than before.
Previous/original keyboard navigation was clear and unambiguous, the "Save" button was marked in green, to make it clear that ENTER/RETURN would trigger it as default action.
Now, the only way to use the dialog via keyboard is via locale-dependent ALT key, in this case ALT-S for English locale.
In addition, keyboard navigation via ALT-<letter> is notoriously unreliable as many UIs and UI translations are not properly designed and tested for it.
For example, often, the same key will have been assigned to multiple UI elements, or none will have been assigned (simply because the translator might not even be aware of this keyboard shortcut function).

(2)
The current behavior is more dangerous than before.
The new behavior shows no warning whatsoever if the file already exists.
The file is overwritten without any indication of the fact.
This is HIGHLY dangerous!

Please restore reliable keyboard navigation, and re-enable the file exists warning.

Side Note - the portal picker is no alternative:
The portal file picker on my system (Ubuntu 24.04, X, Gnome) is utterly unusable for me, thus my reliance on the built-in method.
It is never initially focused for keyboard input - must use mouse to give focus to the portal file picker window.
It's VERY slow, takes more than 10 seconds for it to become usable if the folder contains several hundred files.
It is also VERY sluggish on keyboard navigation (seconds, again).

Comment 5

[shibotto]

I read https://github.com/mozilla-firefox/firefox/commit/d07538533f1ab3d14e6ee7a58b928c26d952d754 and I agree that it makes sense for files open/upload, but can this please be restored for save/downloads? I also confirm (2) by Dominique which I hadn't noticed before.

Comment 6

[Martin Stránský [:stransky] (ni? me)]

That was changed in Bug 2033848.

Comment 8

[Dominique Kaiser]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #6)

That was changed in Bug 2033848.

I get "You are not authorized to access bug 2033848."

Comment 9

[Martin Stránský [:stransky] (ni? me)]

Added needinfo to folks from bug 2033848.

Comment 10

[:Gijs (back August 25; he/him)]

I was not involved in the reviews. I did note in bug 2033848 comment 9 that we should make sure that this didn't affect people's workflows in "save page as" and other fully user-initiated actions (that don't use a website), by using flags or other mechanisms to control filepicker behaviour on a case-by-case basis. Did that not happen?

Comment 11

[:Gijs (back August 25; he/him)]

(the original bug seems specific to upload and so perhaps passing whatever flag it is only for the <input type=file> or similar usecases from web content would be sufficient? But I haven't thought about this much, I could be missing something.)

Comment 12

[:Gijs (back August 25; he/him)]

With apologies for the spam - I guess the other approach here is... for what usecases did chromium make a change in their equivalent bug/report?

Comment 13

[Thinker Li [:sinker]]

Very similar behavior to the bug 2033848 will happen for saving file. It could be used to over-write a file. The web site can ask you to upload a program binary or some thing, and use the same trick to overwrite that specific file. However, this should involve a security review.

I don't follow (2) of the comment #4. Except the save button is not focus, what have been changed?
Could some one explain it more?

The comment #11 is reasonable for me to have a flag for web content.

Comment 14

[Dominique Kaiser]

(In reply to Thinker Li [:sinker] from comment #13)

Very similar behavior to the bug 2033848 will happen for saving file. It could be used to over-write a file. The web site can ask you to upload a program binary or some thing, and use the same trick to overwrite that specific file. However, this should involve a security review.

I don't follow (2) of the comment #4. Except the save button is not focus, what have been changed?
Could some one explain it more?

The comment #11 is reasonable for me to have a flag for web content.

As shibotto also confirmed, (2) refers to the fact that there is no "file already exists" warning anymore.
If the filename entered in the "Save As" file picker dialog already exists on the file system, upon pressing "Save" that already existing file is overwritten without any warning nor indication with the newly downloaded file.
Previously, if the file already existed, upon pressing "Save", there was a "file already exists" warning with the options to "Cancel" or continue to overwrite.

If the download filename suggested by the website is that of a common script on environment file, then that has a lot of potential for bad, security relevant issues.
Not even mentioning that not having a "file already exists" warning is just not tolerable according to normally expected UI/UX behavior.

Comment 15

[Tim]

I found this bug after bisecting firefox source and identifying commit d07538533f1ab3d14e6ee7a58b928c26d952d754 as the source of a problem I'm having.

Double-clicking to open/upload file stopped working as of Firefox 152. I am in an X11/Pulseaudio-based desktop environment (dwm on Gentoo.) I tried installing xdg-desktop-portal-gtk but the whole xdg-desktop-portal framework requires pipewire which is masked here. This is similar to Dominique Kaiser's issue: xdg-desktop-portal should not be a hard dependency for firefox.

As shibotto suggested, can we please at least make this behavior configurable?

I've worked around it for now by installing the ESR version of Firefox. But apparently this is not recommended, and this problem will presumably come back for me in a future ESR release.

Comment 16

[:Gijs (back August 25; he/him)]

(In reply to Thinker Li [:sinker] from comment #13)

Very similar behavior to the bug 2033848 will happen for saving file. It could be used to over-write a file. The web site can ask you to upload a program binary or some thing, and use the same trick to overwrite that specific file.

I'm afraid I don't quite follow. When saving files the website can suggest a filename (via download attribute or Content-Disposition header). When we automatically save (without prompting) we will unique-ify the filename so we will never overwrite. If the user configures Firefox to always prompt to save, typically the OS dialog will (a) open in the default downloads directory (or previously used directory for the same origin) which won't contain such sensitive files, and then (b) complain if overwriting something, before letting the user confirm. Also, none of "save file" would upload information to a website, so it's not really the same risk as bug 2033848, in that no information leaks to the website. The worst a website can do is overwrite an existing file in a location for downloaded files, if and only if the user goes along with some kind of clickjacking/key-jacking thing That doesn't seem all that serious.

In any case, if this is based on a filepicker flag then we could choose to have the same behaviour for website-triggered saves, but not "save page as" and "save link as" which both demonstrate user intent.

Comment 17

[Dominique Kaiser]

(In reply to :Gijs (he/him) from comment #16)

I think that's simply a typo in comment #13 - think "download" where they wrote "upload" - then it makes sense.

Also, are you trying to argue that overwriting a file is no or only a minor concern, just because it might "just only" happen in the "Downloads" folder?
That does not compute for me - overwriting without prior warning is NEVER, EVER acceptable!

More so, I have activated "Ask where to save files before downloading".
The "Save As" dialog always pops up, and it remembers the last used folder.
I.e.: The overwriting happens not just in the "Downloads" folder.
It also has never unique-ified the download file name - that's only a thing if the above option is turned off, I believe.

So, we still have two incorrect behaviors, both stemming from this change, both being regressions:
(1)
Usability and UX standards
Keyboard workflow is not working anymore.
(ALT-S actually does not always trigger the "Save" button, it can also trigger the "Search" function that is part of the GTK file picker dialog.
(2)
Security and data consistency issue
Unprompted (no warning "file already exists") and traceless (no indication that a file was overwritten, afterwards) overwriting of local files.

Comment 18

[:Gijs (back August 25; he/him)]

(In reply to Dominique Kaiser from comment #17)

(In reply to :Gijs (he/him) from comment #16)

I think that's simply a typo in comment #13 - think "download" where they wrote "upload" - then it makes sense.

Well, I would expect overwriting files to prompt for confirmation.

Also, are you trying to argue that overwriting a file is no or only a minor concern, just because it might "just only" happen in the "Downloads" folder?

No. I said:

When we automatically save (without prompting) we will unique-ify the filename so we will never overwrite.

So in the default configuration, we would never overwrite. Full stop.

If the user configures Firefox to always prompt to save, typically the OS dialog will (a) open in the default downloads directory (or previously used directory for the same origin) which won't contain such sensitive files, and then (b) complain if overwriting something, before letting the user confirm.

I don't personally use Linux as a daily driver, but on macOS and Windows the file picker dialog from the OS would prompt before overwriting. You noted elsewhere that it used to do that and now doesn't; that seems like a separate bug (that may have the same cause, or not, I'm not sure).

The note about "such sensitive files" was in relation to uploads which were the subject of the regressing bugs (so sending files to a malicious webpage). It seems typical to me that people do not store sensitive data they upload in their default downloads location, or if they do, that predicting the filenames for the deliberate sake of a collision on the part of an attacker is going to be difficult. Relatively speaking, in the general case the harm from overwriting a file with garbage by an attacker is lower than uploading a sensitive file stored on disk to the attacker (even if I'm sure a counterexample could be constructed, of uploading something harmless and overwriting something terribly important - that won't be what the attacker is striving for in either uploads or downloads).

Edit: perhaps a better clarification is that I was looking at this from the perspective of "harm that could be caused by a malicious attacker, on purpose, by means of clickjacking or similar techniques, and how it does/doesn't align with their goals", which is quite different from "acceptable behaviour for software in normal use, without any attackers involved". Overwriting files should warn, but if there e.g. wasn't clickjacking protection on the "are you sure you want to overwrite" prompt, that allows for less harm from an attacker than having no clickjacking protection on uploading files.

Comment 19

[:Gijs (back August 25; he/him)]

I just realized this got triaged to S3. I don't think that changing the default button in all file dialogs (and breaking double clicks, and apparently also the overwrite warning?) should count as S3 - it should be considered more serious than that.

Comment 21

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2033848

Comment 22

[Thinker Li [:sinker]]

I just checked that the behavior of GNOME's portal file picker. It will show a "Save" or "Replace" depending on if the file exists. And, the default action of the popup of "Replace" is "Cancel" if the "Replace" button triggers. It is a better solution in comparison with the default behavior of GTK.

WDYT?

Comment 23

[Dominique Kaiser]

(In reply to Thinker Li [:sinker] from comment #22)
The functional behavior is fine if ENTER/RETURN will trigger both "Save" as well as "Replace" ("Replace" then ALSO showing the popup to cancel or overwrite).
The question is performance/snappiness - i.e. the non-functional aspect..
Afaik, using the xdg-portal will trigger exactly that GNOME file picker (if used on a GNOME-based system, like mine is).
In my case, that file picker's performance is so incredibly bad that it becomes unusable, especially if you have a larger number of files in the folder (the more files, the slower).
-> Part of that might be that whenever the filename is modified (entering key-press by key-press), with every key-press it triggers the logic to decide between displaying the "Save" or "Replace" button, likely also always triggering a re-layouting of the UI due to the differently sized buttons.

Simply put, the original behavior pre-152 was perfectly fine, it had excellent performance, was keyboard-navigation friendly, and displayed an easy-to-use "file exists" popup if needed.
Afaik, the pre-152 built-in GTK file picker did not dynamically switch between "Save" and "Replace" buttons.

If we could get that Save file picker back as it was, while keeping the new behavior for the Open/Select file picker (e.g. for selecting files to upload), that would be the easiest and best path, imo.

Comment 24

[Thinker Li [:sinker]]

I was not saying to replace it with portal filepicker although it already uses the portal one for most circumstance.

I was saying to make the GTK filepicker behave like GNOME portal one.
It needs several changes

• Save mode
  • The default action of the Save mode is Save button.
  • It will popup a warning dialog for overwriting, and the default action of the popup is Cancel button instead of the original Save.
• Open mode
  • No default action -- Enter will be inert.
  • enable double-click

Each item above need corresponding hacks on the GTK filepicker.

Comment 25

[Thinker Li [:sinker]]

Attachment: Bug 2047865 - Restore Enter-to-save, overwrite warning, double-click, and recent-list in the non-portal GTK file picker. r?stransky

Bug 2033848 (commit d07538533f) made the non-portal GTK file picker safer
against keyjacking: it changed the accept button to use a custom response id
(kFilePickerAccept) instead of GTK's standard one, and stopped marking it as
the dialog's default button. That is the right thing to do for <input type=file>
upload dialogs, where a stray or held-down Enter must not confirm a selection by
itself.

The problem is that GTK only runs a lot of its file-chooser behavior when the
accept button uses one of GTK's standard response ids. By switching to a custom
id and dropping the default button, we accidentally turned off four things for
everyone using the non-portal picker - including ordinary saves, where the
keyjacking concern does not apply:

1. Enter does nothing in the save dialog (there is no default button).
2. No warning before overwriting a file - it is silently replaced.
3. Double-clicking a file no longer accepts and closes the dialog.
4. Files you pick are no longer added to the "recently used" list.

This patch brings all four back for the non-portal picker, while keeping the
keyjacking protection for the open/upload case. The portal path is unchanged
(the desktop portal handles its own confirmation and recent-file list).

• Save mode: mark the accept button as the default again, so Enter and
  double-click confirm the save.
• Open modes: still leave no default button, so a stray or held Enter cannot
  confirm by itself. Restore double-click with our own "file-activated"
  handler that accepts only when the activation came from the mouse, not the
  keyboard.
• Overwrite warning: turn GTK's built-in one off (it cannot run with our
  custom id, and its default button is Replace, which would defeat the
  keyjacking protection) and show our own instead, reusing GTK's translated
  text but defaulting to Cancel.
• Recently-used list: add the chosen files ourselves, the same way GTK
  normally would.

Tested on a local desktop build (non-portal path,
widget.use-xdg-desktop-portal.file-picker = 0):

• Enter saves in save mode; double-click accepts in both modes.
• Enter does nothing on a selected row in open mode (keyjacking protection
  still holds).
• The overwrite warning appears in save mode and defaults to Cancel.
• Saved files show up in the "recently used" list (recently-used.xbel).

Comment 26

[Emilio Cobos Álvarez [:emilio]]

Given the default now is the portal picker tho, do we really want to spend the effort to fix this?

Comment 27

[Tim]

Thinker Li's patch worked for me, fixing the double-click issue in a non-portal environment.

Comment 28

[:Gijs (back August 25; he/him)]

(In reply to Emilio Cobos Álvarez [:emilio] from comment #26)

Given the default now is the portal picker tho, do we really want to spend the effort to fix this?

There's this bug and 2 dupes within a week of the regressing change making to release, so I don't know about "the default" but it does seem this is breaking a lot of people's workflows.

Comment 29

[Emilio Cobos Álvarez [:emilio]]

Ok, fair. I'm just a bit concerned about making a fallback path more complicated than it needs...

Comment 30

[BugBot [:suhaib / :marco]]

The bug is marked as tracked for firefox152 (release), tracked for firefox153 (beta) and tracked for firefox154 (nightly). However, the bug still has low severity.

:jstutte, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 31

[Jens Stutte [:jstutte]]

I am slightly hesitant to mark this S2. There is a viable work-around, AFAICT? Also the proposed patch is not exactly a one liner, so uplifting this all the way to release may seem a bit risky, Ryan?

Comment 32

[Hanno Boeck]

(In reply to Jens Stutte [:jstutte] from comment #31)

I am slightly hesitant to mark this S2. There is a viable work-around, AFAICT?

What is the viable workaround? (I read all the comments above and haven't found any option to configure this behavior. Given that this a really annoying usability regression, I would very much like to know if there is a workaround.)

Comment 33

[Jens Stutte [:jstutte]]

If I read this correctly you can just not hit enter directly but click? I did not try it, admittedly, so better ask :sinker.

Comment 34

[Hanno Boeck]

(In reply to Jens Stutte [:jstutte] from comment #33)

If I read this correctly you can just not hit enter directly but click? I did not try it, admittedly, so better ask :sinker.

Ok, but that's not really a solution, it's "here's a very annoying way to do this everyday action".

It's a major usability regression and, IMHO, a fix should not be delayed any more than necessary.

Comment 35

[Thinker Li [:sinker]]

IMHO, s3 is enough for annoying behavior. But, I think it is right to move to s2 since missing overwrite warning is more serious than just annoying.

Comment 37

[jared]

Hi, as the submitter of bug 2049761 please let me share my experience.

My affected use-case and workflow: I manage several websites using WordPress as a content publisher. I often need to upload many images as I write articles/pages. I perform the upload by 1) type the leading characters of the filename and 2) press Return to insert the image. Often, I repeat this process over 100 times in a session. But now, I cannot press Return (or even double click the file!) to upload it, which has hampered my efficiency. I would imagine my workflow is similar for other bloggers/content editors.

Not all desktop environments use xdg-desktop-portal packages. I've tried using xdg-desktop-portal-gtk, but it takes much longer to launch the GtkDialogWindow (affecting my work speed) and continues to grow in memory usage as you navigate more directories -- never reclaimed until machine shutdown. So, I would be greatly appreciative of the effort to restore the default behavior of the native GtkFileChooserDialog to perform the highlighted action in green with Return/enter, which is much more intuitive, accessible, and doesn't require me running a persistent service just for a file dialog.

Comment 38

[jared]

If I may just add a few more observations:

Firefox now defaults to use the portal via widget.use-xdg-desktop-portal.file-picker = 2. So I tested 5 popular portal picker dialogs:

1. xdg-desktop-portal-kde
2. xdg-desktop-portal-gnome
3. xdg-desktop-portal-gtk
4. xdg-desktop-portal-xapp
5. xdg-desktop-portal-lxqt

Findings: All 5 pickers accept Return for Open File/Save Page As and double-click for Open File.

Only Firefox's fallback GtkFileChooserDialog differs here, not allowing either Return or double-click on a file.

Since you can navigate into a folder with Return, but not open a file with Return, it appears as if uploads are blocked. My first encounter had me think "hmm... restricted file-type?" after pressing Return on a file, then double-clicking the file to no success, before I eventually realized I had to click the button with my mouse.

I'd imagine pressing Return for the file you want to select is a common flow for many others as it is for me. I've never used a file picker that behaves this way in any other program/OS.

Comment 39

[Thinker Li [:sinker]]

I have abandoned the patch in comment #25. Bug 2036097 will introduce a time-based solution instead. Once that lands, I will revert the changes from Bug 2033848.

The new approach implements a 500ms delay before files can be opened or saved. Users can still press Enter or double-click to proceed, but they will need to wait 500ms after the dialog appears for those actions to enable.

Comment 40

[Jan Claeys]

I am slightly hesitant to mark this S2. There is a viable work-around, AFAICT?

There is no workaround for the overwriting / DATA LOSS behaviour.

Also the proposed patch is not exactly a one liner, so uplifting this all the way to release may seem a bit risky, Ryan?

The original patch with its completely broken behaviour was released immediately without proper testing, and without code review by someone understanding the code, so maybe “it might break something” is not the most convincing argument at this point…

Comment 41

[Tim]

(In reply to Thinker Li [:sinker] from comment #39)

I have abandoned the patch in comment #25. Bug 2036097 will introduce a time-based solution instead. Once that lands, I will revert the changes from Bug 2033848.

The new approach implements a 500ms delay before files can be opened or saved. Users can still press Enter or double-click to proceed, but they will need to wait 500ms after the dialog appears for those actions to enable.

I get permission denied on 2036097, so I can't confirm the new patch solves the problem as effectively as the patch in comment #25.

I'm concerned that time-based solutions are also not great. In particular, 500ms seems kind of arbitrary, and may introduce friction for anyone whose muscle memory allows working faster than what on the face of it might seem a brief amount of time. Eg I definitely notice the difference between 500ms and 200ms when adjusting repeat-key rate in xset.

Comment 42

[Thinker Li [:sinker]]

(In reply to Tim from comment #41)

I'm concerned that time-based solutions are also not great. In particular, 500ms seems kind of arbitrary, and may introduce friction for anyone whose muscle memory allows working faster than what on the face of it might seem a brief amount of time. Eg I definitely notice the difference between 500ms and 200ms when adjusting repeat-key rate in xset.

AFAIK, it is adjustable. If you really want a shorter delay, you can set it to 200ms.

Comment 44

[shibotto]

First of all thank you very much for taking this issue into serious consideration. The moment I opened this report I was ready to be dismissed with "just use the portal", so I'm very happy to have been proven wrong.
I have the feeling this is being overengineered a little though, but I don't have access to the linked issues so I could be missing some important details. If the original motivation for this change was to prevent having a pre-selected file on open/upload that could be sent accidentally (or by tricking the user), maybe just removing gtk_file_chooser_set_current_folder() could be enough? This way the GTK file chooser defaults to the "Recent" tab, with no pre-selected files to be Enter-ed. The downside is that the open file chooser won't start on your last location of course.
I also like a lot the overwrite confirmation on comment #25 with the Cancel button as the default one, which I think makes much more sense than Replace as per GTK default.

Comment 45

[Martin Tournoij]

Given the default now is the portal picker tho, do we really want to spend the effort to fix this?

I installed xdg-desktop-portal-gtk via my package manager and that fixed it.

I'm not really clued up on what "xdg desktop portal" is exactly and I don't have access to the linked security issues, but it now seems to work as before with Enter and double-click working.

I don't know if there's any downsides to this, but I do now that now it's just really confusing. I would have preferred a hard "you must install this" error or something over this. Adding an extra dependency is fine; but adding an extra dependency and then falling back to some semi-broken thing when it can't find it, is not really useful for anyone IMO.

Comment 46

[Tim]

I installed xdg-desktop-portal-gtk via my package manager and that fixed it.

I'm not really clued up on what "xdg desktop portal" is exactly and I don't have access to the linked security issues, but it now seems to work as before with Enter and double-click working.

I don't know if there's any downsides to this, but I do now that now it's just really confusing. I would have preferred a hard "you must install this" error or something over this. Adding an extra dependency is fine; but adding an extra dependency and then falling back to some semi-broken thing when it can't find it, is not really useful for anyone IMO.

I think for most people the xdg-desktop-portal ecosystem is recommended, because the most common desktop environments are now using pipewire. I understand xdg-desktop-portal is explicitly about supporting pipewire.

If you installed firefox via your distro's package manager, and it's a distro that has made pipewire the default, then it could be worth raising a bug with them, as it seems like they could be missing a dependency which would have pulled in xdg-desktop-portal or so as needed?

If I understand correctly, the fallback exists for recalcitrants like me who have reasons for not (yet) using pipewire and therefore can't use xdg-desktop-portal.

Comment 47

[Martin Tournoij]

(In reply to Tim from comment #46)

I installed xdg-desktop-portal-gtk via my package manager and that fixed it.

I'm not really clued up on what "xdg desktop portal" is exactly and I don't have access to the linked security issues, but it now seems to work as before with Enter and double-click working.

I don't know if there's any downsides to this, but I do now that now it's just really confusing. I would have preferred a hard "you must install this" error or something over this. Adding an extra dependency is fine; but adding an extra dependency and then falling back to some semi-broken thing when it can't find it, is not really useful for anyone IMO.

I think for most people the xdg-desktop-portal ecosystem is recommended, because the most common desktop environments are now using pipewire. I understand xdg-desktop-portal is explicitly about supporting pipewire.

If you installed firefox via your distro's package manager, and it's a distro that has made pipewire the default, then it could be worth raising a bug with them, as it seems like they could be missing a dependency which would have pulled in xdg-desktop-portal or so as needed?

If I understand correctly, the fallback exists for recalcitrants like me who have reasons for not (yet) using pipewire and therefore can't use xdg-desktop-portal.

I just use pulseaudio; I have a simple Void Linux system with a dwm-type WM. libpipewire.so is a dependency of xdg-desktop-portal, but that's also the case for e.g. mpv and qemu-system-amd64. I just use pulseaudio with mpv.

Like I said, I don't really know what this xdg-desktop-portal is all about, or how pipewire fits in. All I know is that I installed a package and that seems to have fixed it with no ill effects that I can determine.

Comment 48

[jared]

(In reply to shibotto from comment #44)

I have the feeling this is being overengineered a little though, but I don't have access to the linked issues so I could be missing some important details. If the original motivation for this change was to prevent having a pre-selected file on open/upload that could be sent accidentally (or by tricking the user), maybe just removing gtk_file_chooser_set_current_folder() could be enough? This way the GTK file chooser defaults to the "Recent" tab, with no pre-selected files to be Enter-ed. The downside is that the open file chooser won't start on your last location of course.

From what I've read here, the current proposal is comment 39: a 500ms or shorter delay that still accepts Return/double-click in both Save/Open dialogs. In my opinion, that's a much better solution than the earlier patch comment 25, which still blocked the Return key in Open dialogs. The delay approach is also less of a tradeoff than losing the current directory with your Recent tab idea. Imagine how tedious it would be uploading media/opening files from a specific folder, especially if it's deeply nested in the filesystem. You'd have to re-navigate each time.

(In reply to Martin Tournoij from comment #47)

Like I said, I don't really know what this xdg-desktop-portal is all about, or how pipewire fits in. All I know is that I installed a package and that seems to have fixed it with no ill effects that I can determine.

The xdg-desktop-portal backends (like I tested in comment 38) provide different file choosers/dialogs for Firefox to use instead of its built-in file chooser/dialog. That's why Return/double-click now works: you're seeing a different dialog provided by xdg-desktop-portal-gtk, despite it looking the same as the built-in dialog (both are GTK-based).

One drawback is now you have xdg-desktop-portal and xdg-desktop-portal-gtk services running in the background during your graphical session. On my system, the combined memory usage of these two starts at 60 MiB after boot and grows over 100 MiB after a few open dialogs: long sessions continue to use more.

Another drawback is the xdg portal dialogs often launch slower/perform worse than Firefox's built-in dialog, as noted in comment 4. This varies by backend (xdg-desktop-portal-gnome/gtk/kde, etc.).

Comment 49

[shibotto]

(In reply to jared from comment #48)

From what I've read here, the current proposal is comment 39: a 500ms or shorter delay that still accepts Return/double-click in both Save/Open dialogs. In my opinion, that's a much better solution than the earlier patch comment 25, which still blocked the Return key in Open dialogs. The delay approach is also less of a tradeoff than losing the current directory with your Recent tab idea. Imagine how tedious it would be uploading media/opening files from a specific folder, especially if it's deeply nested in the filesystem. You'd have to re-navigate each time.

Tbh I don't remember the last time I used the open dialog, I usually drag and drop files from a file manager, but trying right now on my Nextcloud instance I can select multiple files to upload at once. I see in the code that this is nsIFilePicker::modeOpenMultiple, but I don't know what decides that, so does this work on every website?
Also something someone might have never noticed: if for example you upload one file, you'll find it in the Recent panel right after, then you can right click -> Visit File to navigate the file chooser to its directory.

I'm not fixed on this, everything works for me as long as the Enter key works again, but if it were me I'm just a fan of keeping things as simple as possible.

Comment 53

[macias]

Can someone can explain what are the dangers of saving the file with default Enter action key? It works across all regular programs and only thing is overwrite existing file, but then there is another dialog for that. So actually there is no danger.

This change breaks decades long behaviour and adds more friction and what's more adds ton of extra friction to "disabilities" box -- hitting Enter key is pretty cheap in sense of movement, while cycling with "Tab" key to focus on "Save" is usually much more expensive (in this case is impossible). Using mouse instead of Enter key is also more expensive because it requires movement (action+precision) and hitting key (this part alone has the same cost as Enter key).

So basically I don't see any benefit, while adding cost to daily life. Work at computer should be other way around.

Comment 55

[Dominique Kaiser]

(In reply to Dominique Kaiser from comment #4)
Behavior is even worse than what I originally described, there's a third variant to this regression:
(3)
Data inconsistency
If the "Search" function is active, triggering the "Save" button (via mouse or via keyboard ALT-S) does animate the "Save" button normally, but it does not actually save anything.
This can lead to believing that something was saved safely, only to discover hours, days, weeks later that the expected file is missing.
This scenario is exacerbated by the fact that, on English locale, ALT-S can sometimes trigger this Search function instead of triggering the Save button. Using ALT-S a second time then also leads to the above faulty behavior.

Urgh, I'm not even clear how something can trigger the "Save" button animation, close the dialog, but then end up not save anything.
As others remarked, the current behavior is both significantly faulty, and it does not comply with any reasonable expectation to normal UI behavior.
Talking about not risking any further changes via code patches seems misguided as the change that caused this regression has evidently lead to much more risk exposure, and was maybe not properly risk assessed.

Comment 56

[Dominique Kaiser]

(In reply to Tim from comment #46)
It's not just about dependencies regarding pipewire / audio.
In my case (Ubuntu 24.04, Gnome, X11 instead of Wayland), I have the portal packages installed, but the portal file picker is utterly unusable.
(a)
It's not usable without some mouse usage.
(b)
Its performance is very noticeably bad if a folder has hundreds of files.
And I've tried a few times with a folder with thousands of files -> it is then so slow as to being utterly, totally unusable.

This is obviously a Linux-only issue, and only for some Linux variants.
But my Ubuntu variant is nothing out of the ordinary.
And this is exactly why the non-portal fallback exists in Firefox, in the first place.
The only thing that is unusual in this scenario is me preferring to use keyboard-only navigation for some UI activities.

A thought:
Has someone considered the impact of this regression on accessibility? I'm not familiar enough with this to be able to assess this myself.

Comment 57

[Zdenek Kabelac]

Since I'm using 'mate' desktop - I've manage to replace Gtk file dialog to be replace with lxqt file chooser - following this guide:

https://wiki.archlinux.org/title/XDG_Desktop_Portal

So while it's not matching UI look however 'Enter' works again, so just if someone would seek for around - this one works 'good enough'.....

Comment 58

[Zdenek Kabelac]

(In reply to Zdenek Kabelac from comment #57)

Since I'm using 'mate' desktop - I've manage to replace Gtk file dialog to be replace with lxqt file chooser - following this guide:

https://wiki.archlinux.org/title/XDG_Desktop_Portal

So while it's not matching UI look however 'Enter' works again, so just if someone would seek for workaround - this one works 'good enough'.....

Comment 60

[Martin Stránský [:stransky] (ni? me)]

I wonder if we may add a pref to revert to enable to revert to previous state?
The CVE-2026-12322 is rated as sec-low so perhaps it may be more important to keep the previous behavior for someone.

Comment 61

[teika kazura]

Obviously this fix was a terrible QoL bug. Does't it suffice to delay the dialogbox until the Enter key is released? (I know, someone should send a patch.)

An accessible explanation of this security bug is available at < https://sawahcyber.id/en/blog/clickjacking-in-mozilla-firefox-gtk-file-picker-cve-2026-12322 >, the reporter company's website.

# I installed xdg-desktop-portal, and it pulled in a big headache.

Thanks mozilla developers.

Comment 62

[Martin Stránský [:stransky] (ni? me)]

AFAIK there's a plan to move forward here.

Comment 63

[Thinker Li [:sinker]]

(In reply to teika kazura from comment #61)

Obviously this fix was a terrible QoL bug. Does't it suffice to delay the dialogbox until the Enter key is released? (I know, someone should send a patch.)
There is another patch on the way.

Comment 64

[dalgoda+github]

Something I just noticed is the inconsistency between this UX and other choosers.

For example, when launching with -P to select a profile.

As a user, the UX are similar, visually, and I would expect them to act consistently.

If we are forced to use the Ok button in one, we should be forced to do so in both.

Otherwise, one seems broken

To put this into a security domain: inconsistent user experiences can be confusing and lead to security issues.

Comment 66

[Jan Brasna [:janbrasna]]

Since bug 2036097 this depends on can't be followed by most, this is just an update it's been fixed and the change now including a standard clickjacking timeout ee0fd8bc has landed in Nightly already.

Does it mean that some of the values from bug 2033848 added in d07538533f now need/ought to be revised to resolve this bug?

Comment 67

[shibotto]

Will this land in a 153.0.x? As of 153.0 it still has this questionable behavior including the very dangerous overwrite without confirmation.

Comment 68

[peter_jonson]

(In reply to Martin Stránský [:stransky] (ni? me) from comment #2)

Yes, it was decided to remove the default action to make sure the 'accept' is not selected accidentally.

That change was not necessary for downloads, and introduced the worse problem of quietly destroying user data, of potentially unlimited importance, that they may be unable to replace. And therefore destroying trust in Mozilla.

Replying to other comments:

An accessible explanation of this security bug is available at < https://sawahcyber.id/en/blog/clickjacking-in-mozilla-firefox-gtk-file-picker-cve-2026-12322 >, the reporter company's website.

A malicious page can make a file dialog confirm itself and, at worst, read one file

Sounds like it is about reading, not writing, so the fix is only needed when reading. Making it silently destroy user files that they may be unable to replace is therefore completely unnecessary.

Also, are you trying to argue that overwriting a file is no or only a minor concern, just because it might "just only" happen in the "Downloads" folder?
No. I said:
When we automatically save (without prompting) we will unique-ify the filename so we will never overwrite.

But when the user chooses the filename, it silently overwrites. So they have to check the entire list of existing files, which may be in an unpredictable order, eg sorted by name, date or size, to try to make sure their chosen name isn't already there.

I installed xdg-desktop-portal-gtk via my package manager and that fixed it.

I already had it installed, and firefox still used its own built in file chooser, and the overwrite behaviour happened.

This bug is partly about the situation where save overwrites existing files. I searched https://bugzilla.mozilla.org/buglist.cgi?quicksearch=save%20overwrites&list_id=18049618 and it didn't find this bug.

Comment 69

[peter_jonson]

In version 153.0 this bug fix concerning the file upload dialog still causes the file download dialog to overwrite files without consent.

Comment 70

[Dominique Kaiser]

(In reply to peter_jonson from comment #69)

In version 153.0 this bug fix concerning the file upload dialog still causes the file download dialog to overwrite files without consent.

According to https://bugzilla.mozilla.org/show_bug.cgi?id=2056152 it is fixed for version 155.
Which seems strange that it is not 154, as 153 was only just released.
Though, it was mentioned that a beta testing phase is desired, so maybe that's the reason... I still hope that the fix can be applied to 154, as well.

Both the overwriting as well as the sometimes not saving at all are both becoming more and more tiresome to me.
I've had both screw things up for me, already.

Comment 71

[Jan Brasna [:janbrasna]]

Yes, everyone affected is welcome to help verify the changes using today's Nightly v155 nightly.mozilla.org build 20260722100459 and newer. Thanks!

Comment 72

[peter_jonson]

(In reply to Jan Brasna [:janbrasna] from comment #71)

Yes, everyone affected is welcome to help verify the changes using today's Nightly v155 nightly.mozilla.org build 20260722100459 and newer. Thanks!

I tried firefox-155.0a1.en-US.linux-x86_64.tar.xz (Help->About Firefox says "155.0a1 (2026-07-22)" and doesn't give a version number in the format you mentioned).

It worked on one machine (pressing return in file chooser dialog causes save, unless there is a file of same name, then it asks what to do). On another machine on the account that owned the gui it worked. But on another account that was using xwayland (and with possibly broken dbus), no dialog appeared and no error/suggestion appeared (including on the cmdline where it was started). Same from File-Save page, and Tools->Page Info->Media->Save as.

The workaround in that case is to go to about:config and set widget.use-xdg-desktop-portal.file-picker to 0. Then it works. The file chooser appears, return saves, unless there is a file of same name, then it asks what to do. Clicking 'Save' in the file chooser dialog also appears to work correctly. I don't know much about the original upload bug, so I don't know if this workaround reintroduces that security vulnerability.

Comment 73

[Jan Brasna [:janbrasna]]

If you want to verify even the keyjacking vector, it's very nicely described for QA in bug 2056152 comment 8

(If the question is about whether widget.use-xdg-desktop-portal.file-picker: 0 affects the mitigation — no, that's the non–portal path that is actually being fixed here, so that's the correct pref for the above.)

Comment 74

[Thinker Li [:sinker]]

The fixes has been uplifted to 153.

Comment 75

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected, along with ESR.
:sinker, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta and ESR approvals.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox154 and the ESR status flag(s) to wontfix.

For more information, please visit BugBot documentation.

Comment 76

[Mathew Hodson]

Firefox 152 should be marked as "wontfix" not "unaffected". The commit that introduced the affected code was https://hg-edge.mozilla.org/mozilla-central/rev/984fa350913586b986271852a6b29b0261a26ddb which landed in Firefox 152.

Comment 77

[Jan Brasna [:janbrasna]]

The changes depend on the underlying security fix so the uplifts stopped at 154.0b2 and didn't make the last 153.0.4 release as they depend on more things — this will eventually ship in 154.0 and 153.1.0esr about a week and half from now according to current trains.