That article does not seem to mention generic troubleshooting steps — if you check Troubleshoot and diagnose Firefox problems there's 3.) trying restarting in Safe Mode, and 6.) trying a fresh disposable profile — to see if the woes persist across isolated sessions and profiles.

I tried Troubleshoot (or Safe) mode. I tried a new profile. None of these changed anything. The article I mentioned suggested these. In summary, I did the following.

1. Restart your computer 2. Clear your cookies and cache 3. Restart Firefox in Troubleshoot Mode 4. Reinstall Firefox 5. Refresh Firefox 6. Create a new Firefox profile

Plus, I used "about:config" and looked for the "browser.download" options, but then realized that I didn't really know what they were supposed to be, and so didn't change any of those. The page that I found that suggested the following 5 config settings:

browser.download.dir browser.download.downloadDir browser.download.folderList browser.download.lastDir browser.download.useDownloadDir

but I only have browser.download.folderList (1) and browser.download.useDownloadDir (true).

This might very well be a candidate for filing a bug, if a fresh profile exhibits the same:/

Couple of obnoxious questions: Is this a recent change? Do you recall if/when this worked as expected? Does your installation come from Flatpak, some RPM repo, or a Mozilla binary? Would you be willing to try the official Mozilla RPM repo for the most "vanilla" experience? If you feel it's a recent change, would you be able to run mozregression to see if there's a good/bad version boundary at some revision?

Sorry if this is stupid question: Do arbitrary downloads work, like… just clicking https://file-examples.com/wp-content/storage/2017/10/file_example_ODP_200kB.odp — or clicking the image in https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_a_download that should "just" download, somewhere, and trigger the previously hidden toolbar icon with it.

Or this only affects the "Save as…" elements from contextual menu?

An excellent question! Those two links download just fine. And I now have a download button in my toolbar. (Clicking on it, it shows a button for "Hide Button When Empty", which would explain why it was missing, I guess.)

This seems just to be a problem with "Save Image as", and maybe the fact that the "Browse" button doesn't work in Settings to set the Download directory.

Also, I have google-chrome on my system, but normally don't use it unless Firefox seems to not work. But if I bring it up, it has the same behavior. -- Save image as does nothing, And if I go to Settings, Downloads, the "Location" is given as ".../Downloads" but the Change button next to it does nothing. So I suspect that the about:config code is all the same for Firefox and Chrome, and this is where the problem is. Possibly something like the browser.download.dir entry has disappeared for some reason, and the code to access it gets back a NULL and then just punts when I ask it to save a file. Same for the Browse button -- it goes to get the current value, gets a NULL, and just returns. But that's just a guess.

The directory seems set alright as the default, is accessible, writable, and the downloaded entries are correctly saved and listed. The issue seems in desktop integration, trying to bring up the file pickers. (Can you open/save files in other apps like libreoffice or similar? Something using the GTK defaults? What about other file pickers in Firefox? Are you able to add an attachment here using the file picker? Or do "Save Page As…" from the app menu?)

The desktop integrations most likely differ between browsers, so there's nothing in common besides the actual underlying operating system, or, you know, passing a relative path to the desktop portal to open the picker etc. that might fail in the same way.

There's some scattered reports for Sway, Wayland on EOL Fedora versions, plumbing of xdg-desktop-portal settings etc. but it might be helpful to know what Fedora version you use, and what desktop environment you have, or any windowing specifics that come to your mind.

If I just bring up a firefox browser and right mouse to a pop-up menu that says "Save Page As" that also does nothing. Other GTK apps seem to work fine. I have been using GIMP constantly for weeks on a set of files, and can open those with no problem. libreoffice lets me create documents, insert images from the file system, librecalc opens my spreadsheets. As near as I can tell, it's just the Downloads in Firefox (and Chrome).

I can't add an image to this reply. There is the "Add images (optional)" down below with a Browse button, but the Browse button does nothing. I can select it. I get a blue rim around the button, but nothing else comes up to allow me to select a file. And the Save Page As for this page also does nothing. The menu item comes up, turns blue when I'm over it, but clicking it with the mouse (left or right button) just takes the menu down, with no other action.

I'm running the most recent download of Fedora 42 -- 6.19.14-107.fc42.x86_64 with just a pretty standard install. (I have rewritten some of the common utilities for Linux -- ls, rm, cmp, which -- but those are in ~/bin; I can still get to the standard ones in /bin if I need to, but surely Firefox isn't blindly running ls from my bin directory, and I've had those for decades; this problem just came up in the last month or so.) I noticed the problem about the same time as I noticed the "VPN" thing in the default firefox toolbar.

Yeah more like if Mutter/GNOME are the defaults on your system et al., in case you've plugged in some custom Wayland compositor or window manager that be worth mentioning.

Honestly, I don't have a good advice, but if you have a rather vanilla setup, and file a bug, there's chance some of the nice Red Hat folks that diagnose these desktop integration woes will know more.

If you have a suspicion this "might have worked" back in some older version, and wanna try "poor man's mozregression" yourself to have more data points, you can download a Firefox Nightly binary from any arbitrary timestamp, and try running that — Nightlies have separate profiles, so that won't interfere with your day to day browser, and you can go downgrading and upgrading as you see fit for investigation purposes in isolation.

I'll randomly pick a few versions:

• 151.0a1 that would be close to what you're running now, just for control:

https://ftp.mozilla.org/pub/firefox/nightly/2026/04/2026-04-19-20-35-36-mozilla-central/

• 153.0a1 to travel two months forward, if there's any difference:

https://ftp.mozilla.org/pub/firefox/nightly/2026/05/2026-05-21-09-40-38-mozilla-central/

• 148.0a1 to see some downgrading:

https://ftp.mozilla.org/pub/firefox/nightly/2026/01/2026-01-08-16-54-48-mozilla-central/

•  146.0a1 to go back even a bit more:

https://ftp.mozilla.org/pub/firefox/nightly/2025/11/2025-11-05-20-40-25-mozilla-central/

You get the gist;) You'll be able to pick the right binary for your arch or get the package from there I suppose. Signatures are also available in the folders if you need to check the hashes.

I suspect this is not a problem with the actual browser, since I get the same behavior with Firefox and Chrome. And while you say "there's nothing in common besides the actual underlying operating system", I think there is actually a shared "configuration" data base. I remember being surprised when I first brought up Chrome and found that it "knew" a lot about how my Firefox system was configured -- like what my "home" page was set to be.

But hey, this is an open source world, so I went and got the source code for Firefox, not realizing the complexity of it. 466,047 files. But looking at what is there, I realized that most of my problem is not likely to be in C or C++ code. There is somewhere in all this actual code. But the code just creates an engine to display pages. And most of what is done for Firefox is display pages on the screen. Even the settings pages, are just pages. And the best way to build those is not with C++ code, but with Java or JavaScript, or some Mozilla specific version of JavaScript.

Still there has to be a reference someplace in all this source code to the actual displayed text in the Settings page. So I looked for "downloadDir" . The path names for the files that contain that suggest that a lot of the code is test files, since, sure, for a large public project like Firefox, we would want to run a bunch of unit tests before delivering new versions. But we did find a file called firefox-main/tools/profiler/core/platform.cpp, which looked promising, except for the "profiler" part of the path. And then we can see that this is even more complex code, since we have multiple threads running asynchronously, so it needs to get a lock, but we get code like:

   downloadDir = CorePS::AsyncSignalDumpDirectory(lock);

    // This needs to be done within the context of the lock, as otherwise
   // another thread might modify CorePS::mAsyncSignalDumpDirectory while we're
   // cloning the pointer.
   if (downloadDir) {
     nsCOMPtr<nsIFile> d;
     downloadDir.value()->Clone(getter_AddRefs(d));
     directory = Some(d);
   } else {
     return Nothing();
   }

which is like what I fear is the base problem. The design of Firefox depends upon a vast configuration data base -- the thing that you get to with "about:config" which expects there to be a bunch of user specific values that drive how things are done. But if that configuration data base is somehow corrupted, and some name/value pairs are not there, it will just silently do nothing, without any sort of error message.

I would have expected, for example, that there is a single place in all this code that actually goes and gets a configuration value out of the configuration data base, and that the getting of this would be logged someplace. That would allow me to go to the 3-line menu, the "More Tools" submenu and select "Browser Console" or something and then see the list of requests for the configuration data and what was obtained. That would show that I am missing some critical configuration value which drives the "Save Image As" process. But I don't see anything like that under "More tools".

Ah, here we have what is apparently the list of config values it expects: firefox-main/browser/components/preferences/config/downloads.mjs:

var Downloads = ChromeUtils.importESModule(

 "resource://gre/modules/Downloads.sys.mjs"

).Downloads;

Preferences.addAll([

 { id: "browser.download.useDownloadDir", type: "bool", inverted: true },
 { id: "browser.download.enableDeletePrivate", type: "bool" },
 { id: "browser.download.deletePrivate", type: "bool" },
 { id: "browser.download.always_ask_before_handling_new_types", type: "bool" },
 { id: "browser.download.folderList", type: "int" },
 { id: "browser.download.dir", type: "file" },
 { id: "pref.downloads.disable_button.edit_actions", type: "bool" },

]);

And I have all of those, with reasonable looking values.

But this last one looks strange -- a preference related to downloads to disable the button? And I have one that says: services.sync.prefs.sync.pref.downloads.disable_button.edit_actions set to true. Changing it to false does not seem to make an (immediate) difference. The "Browse" button under Downloads in the Settings still doesn't work.

So it seems I'm at a dead end. I could spend months trying to understand the code well enough to find my problem or I can just work around it for now. Maybe when I move to the next release of Fedora it will go away.

Browsers can read each others' prefs to be able to migrate settings, and yes even use the same paths for default locations, but that's just for ease of user setup — these are not continuously synced or shared from the same location, it's more of stealing existing info when starting from clean slate when new;) But as you verified yourself earlier — the location browsers care about is set correctly, is valid, is writable etc. — it's not a download location problem. It's a GTK system dialog problem, based on your inability to also trigger the same file picker for uploading files — which is not a write operation but a read operation, and in theory might have a different "recent" location to populate the system portal, but it still doesn't show up. The "save page" trigger would on most systems use a different set of recent locations, so it's not just like there's a one path that the portal can't read as the starting point and crashes, it seems no file pickers open for you at all, no matter the permission model, mime type / file filter, or (recent) location type.

FWIW it's not in prefs (these would be fine in a clean profile), also the prefs are mainly for defaults when you're not saving to a different location but for when downloads run without your interaction — file pickers are there so you don't need the defaults; and they either open at an implicit path, or they have some (f)recency built in them — believe that's OS level, not client–level.

Browser Console should be exactly where you describe, if not, there are shortcuts to invoke it: https://firefox-source-docs.mozilla.org/devtools-user/browser_console/ — maybe you'll see an event throw or reject a promise or something the moment you try to open a file picker — good idea!

If you feel like changing any of the paths that don't open these pickers for you, you can do that in about:config skipping any UI and changing the paths around freely, skipping the system portal integration. But I don't think that's the issue, the issue is the system portal service failing for these UI needs.

To get the idea what the file picker issue is in broader context, here are some links to other platforms, apps and bugs that might give you some ideas what to try:

• https://wiki.archlinux.org/title/Firefox#XDG_Desktop_Portal_integration
• https://bbs.archlinux.org/viewtopic.php?id=300394
• https://pappp.net/?p=59868
• https://bugzilla.redhat.com/show_bug.cgi?id=2134527
• https://forums.gentoo.org/viewtopic.php?t=1176234
• https://docs.voidlinux.org/config/graphical-session/portals.html
• https://github.com/zed-industries/zed/issues/14874