Karl or glandium, do you know if there's anyone who can help move this issue forward? I don't think any of the (desktop firefox frontend) folks currently working on downloads and file handling in Firefox have the relevant expertise. Based on this and bug 140751 I'm not sure where the issue is; it looks like we rely on an interface with GIO to determine default applications, and presumably that just doesn't work on KDE systems, or something? But comment #9 suggests that we're following the XDG spec (though I don't see any evidence of direct support for that inside Firefox, as far as mime/protocol handling is concerned; afaict we delegate to GIO).

Bug 1713541 comment 17 also (as well as comment 9) indicates that KDE doesn't always use the XDG spec.
Apparently Firefox does end up using default apps that have been explicitly selected, but not KDE's initial default apps.
The way KDE works seems to be that only KDE apps would consider KDE's initial default apps.
IIUC adding KDE's initial default apps into consideration would require a KDE-specific solution; perhaps there are KDE APIs that could be used to workaround. I don't know of people familiar with this.

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

(though I don't see any evidence of direct support for that inside Firefox, as far as mime/protocol handling is concerned; afaict we delegate to GIO).

I assume GIO, or whatever GLib/GTK APIs we use, would provide the XDG support.

It is possible to know what are the files involved in this?
I am asking because I am in touch with the KDE community, and they asked this to see how they can help with that.
I searched on https://searchfox.org/mozilla-central/search?q=mime&path= but I am not sure what is the right one.

(In reply to Daniele "Mte90" Scasciafratte from comment #14)

It is possible to know what are the files involved in this?
I am asking because I am in touch with the KDE community, and they asked this to see how they can help with that.
I searched on https://searchfox.org/mozilla-central/search?q=mime&path= but I am not sure what is the right one.

https://searchfox.org/mozilla-central/rev/ecd91b104714a8b2584a4c03175be50ccb3a7c67/toolkit/system/gnome/nsGIOService.cpp#469

Specifically:

  RefPtr<GAppInfo> app_info =
      dont_AddRef(g_app_info_get_default_for_type(content_type.get(), false));

calls g_app_info_get_default_for_type which is a GTK API that is supposed to provide the default app. Apparently (based on these bugs and context; I haven't checked...) this provides the wrong value under KDE. I don't know why but hopefully KDE folks would have a better idea.

There might be other things that need to be fixed, and/or, given there's a BSD ifdef there that uses xdg-open instead, perhaps we need a conditional that checks if we're on KDE (somehow?) and then uses xdg-open or xdg-mime, per comment #9, like we do on BSD? But I really don't have the expertise to evaluate the specifics. Daniele, is this sufficient for more KDE-literate folks to offer suggestions / a patch?

I shared the ticket to some KDE developers to see how they can help with this.

After discussing it a bit with some GTK devs and testing around a bit, my impression is that it's just g_app_info_get_default_for_type not doing what we expect on KDE Plasma.

I was pointed out as a way to test it locally without having to go through all of firefox is to use "gio open $filename", I could reproduce this issue that way.

Using xdg-open should probably work but it would defeat the purpose of the combo box itself. That said, I find firefox used without GTK_USE_PORTAL=1 is quite unbearable to use but with it enabled it covers most places.

Would it be possible to enable GTK_USE_PORTAL=1 behaviour by default on Plasma-based systems?

(In reply to aleixpol from comment #18)

After discussing it a bit with some GTK devs and testing around a bit, my impression is that it's just g_app_info_get_default_for_type not doing what we expect on KDE Plasma.

I was pointed out as a way to test it locally without having to go through all of firefox is to use "gio open $filename", I could reproduce this issue that way.

Using xdg-open should probably work but it would defeat the purpose of the combo box itself.

Sorry, which combo box is this referring to?

That said, I find firefox used without GTK_USE_PORTAL=1 is quite unbearable to use but with it enabled it covers most places.

It'd probably help the discussion if you were more specific here. What's the relevance of this env var and why/how/where does enabling it help?

Would it be possible to enable GTK_USE_PORTAL=1 behaviour by default on Plasma-based systems?

I don't know, maybe :karlt or :stransky can answer this. There are a bunch of prefs that could potentially be used by users to toggle this behaviour, but from the comments there it would appear there are (or used to be) downsides to the USE_PORTAL stuff, cf. bug 1516290.

Firefox has various prefs for portal behavior in about:config. The default is determined in this function: https://searchfox.org/mozilla-central/rev/b72e9d7d63bf499d1d8168291b93d4ec7fde236e/widget/gtk/WidgetUtilsGtk.cpp#119-125

Tweaking the autoBehavior to use the file portal in KDE should be trivial.

Also the mime handler, perhaps.

It'd probably help the discussion if you were more specific here. What's the relevance of this env var and why/how/where does enabling it help?

My fault, yes. I can see how it's vague.

The difference between having the environment variable or not is basically to use GTK libraries for this kind of integration versus using the xdg desktop portals which is an abstraction that the different environments can implement.

Firefox already depends on these to work properly with snap and firefox it's also the way many Plasma users integrate firefox already because it offers different advantages (like for example showing the correct open and save dialogs). Portals are also necessary for screensharing on Wayland systems (through webrtc).

Others probably know more about portals than I.
I guess the best way to make a case for switching to portals in Firefox, perhaps for a particular environment, before GTK makes the switch would be to identify what's holding GTK back from making the switch and a reason why that would not apply to Firefox or a particular environment.

So if I understand correctly, would fixing this require expanding the "auto" behaviour from https://phabricator.services.mozilla.com/D148782 to also enable portal for KDE? How difficult is determining whether we're on KDE?

Possibly, with the caveats mentioned in comment 23. We check the XDG_CURRENT_DESKTOP environment variable in various places like here.

See also: bug 727422, bug 893799, …

… bug 724461, …