1304650 - Firefox use wrong default applications to open files in KDE5

Status: NEW

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

Description

[Guo Yunhe]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160818000000

Steps to reproduce:

1. Install latest Firefox in Linux with KDE5 desktop.
2. Download a PDF file.
3. Click download icon in toolbar.
4. Open the file in download menu.



Actual results:

Firefox use LibreOffice Draw to open PDF files, rather than default PDF viewer in system. It also use LibreOffice to open all text file, rather than default text editor. It opens all images with GIMP, rather than default image viewer.


Expected results:

Firefox should use default application settings of KDE5.

Comment 1

[William Hsu [:whsu]]

Hi, Yunhe,

Good day,
I'm not sure if the settings of LibreOffice overwrite the PDF settings on Firefox.
May I have your help to check the application preferences by following steps?
Thank you.


Steps:
1. Launch Firefox
2. Type "about:preferences#applications" in URL bar
3. Type "PDF" in search field and check the default application to see if it's "Preview in Firefox"

Comment 2

[Guo Yunhe]

Default PDF action is "Save file". Sorry the screenshot is in Chinese.

http://imgur.com/81XOVvY

Comment 3

[William Hsu [:whsu]]

(In reply to Guo Yunhe from comment #2)
> Default PDF action is "Save file". Sorry the screenshot is in Chinese.
> 
> http://imgur.com/81XOVvY

No worries.
Please chose the "在 Firefox 中预览" to see if it can solve your problem.
I am going to monitor this problem to see if I can get similar cases.
Sorry for any inconvenience.

Comment 4

[Guo Yunhe]

(In reply to William Hsu [:whsu] from comment #3)

> Please chose the "在 Firefox 中预览" to see if it can solve your problem.

This won't solve the problem. Though the PDF file can be previewed inside Firefox, I still need to download some PDF files sometimes. When I downloaded the PDF file and click it in download menu, Firefox use LibreOffice Draw to open it.

Images, like JPEG and PNG, will be opened in GIMP when download finished.

Comment 5

[William Hsu [:whsu]]

(In reply to Guo Yunhe from comment #4)
> (In reply to William Hsu [:whsu] from comment #3)
> 
> > Please chose the "在 Firefox 中预览" to see if it can solve your problem.
> 
> This won't solve the problem. Though the PDF file can be previewed inside
> Firefox, I still need to download some PDF files sometimes. When I
> downloaded the PDF file and click it in download menu, Firefox use
> LibreOffice Draw to open it.
Oh! My bad. I misunderstood the problem.
Because your operation system set LibreOffic as PDF default application, that's why you cannot open it in Firefox.

The article may help you. Have a nice day.
- http://www.ghacks.net/2009/08/24/change-default-and-preferred-applications-in-kde/

> 
> Images, like JPEG and PNG, will be opened in GIMP when download finished.

Comment 6

[Guo Yunhe]

No No No

In my KDE file manager Dolphin, I can open PDF with Okular PDF Viewer by default. But only in Firefox, it ignores the KDE default applications and uses gconf. However, since I am not using GNOME, gconf doesn't have any customized default applications. So Firefox open PDFs with wrong applications.

Comment 7

[Guo Yunhe]

Please do not close this bug!

Comment 8

[:Paolo Amadini]

From what I read here, it seems like an actual problem with platform support in Firefox, but as far as I know we don't have someone on the team that has the expertise needed to fix the bug.

We would probably need a KDE developer or someone with the right expertise to take a look and provide a patch.

Comment 9

[est31]

I've ran into this bug as well, for me it manifests as Firefox suggesting me to open PDF files using GIMP which is obviously not really desirable. This bug is quite nasty as it renders the "open with" option useless.

There is an Freedesktop specification [1] on how to determine the default application for a MIME given type. This specification is actually implemented by Firefox, see bug 694870. However, from what I've read, KDE doesn't seem to conform with that specification. There are a few indicators for this:

* When I run xdg-mime query default application/pdf, it correctly gives me the .desktop file for Okular, not GIMP. However, when I look into the source code for xdg-mime, I see a conditional where the default behaviour is to scan using the freedesktop spec, but the behaviour on KDE is to use a tool called ktraderclient. Now why should the authors of xdg-mime have done that, if not because KDE doesn't use the spec?
* When I force the script to go with the "spec" path on my computer, it doesn't give me a correct result. This seems to be a confirmation. For completion's sake, running ktraderclient --mimetype application/pdf | grep "DesktopEntryPath" gives me correctly the .desktop file for Okular.
* When I run gnome-open <path to pdf file>, it opens me the file with GIMP as well. Most likely gnome-open uses the same API that Firefox also uses to get the default application information. 

However, xdg-mime, Dolphin, and other programs all open the pdf file correctly with okular. Also, in my KDE system settings, Okular shows up as the default application to open pdf files.

Now this means there are two bugs:

* One bug with Firefox, that it doesn't provide better integration with KDE (bug 140751 as a tracking issue).
  In bug 694870 comment 25 it is mentioned that there are patches by SUSE for firefox that do provide better KDE integration, and where this functionality works as expected.
* And one bug with KDE, that it doesn't implement the Freedesktop spec but seems to do its own stuff.

For resolving this on the Firefox side, you could:

* either apply the SUSE patch (not sure if that's possible legally as if it were, why is it still not applied?)
* or figure out how to build against KDE frameworks and then use [2] KMimeTypeTrader to obtain the result (not sure if that's possible legally as the KDE frameworks are under LGPL AFAIK)
* or do it like xdg-mime and add some detection for whether we are on KDE (e.g. by checking the XDG_CURRENT_DESKTOP env var) and if we are, launch a ktraderclient process and parse its output. This should have the least legal issues of the three approaches.

[1]: https://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html#default
[2]: https://api.kde.org/frameworks/kservice/html/classKMimeTypeTrader.html

Comment 10

[abc]

Same problem here.

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0
plasmashell 5.14.4
KDE Frameworks: 5.53.0

Comment 12

[:Gijs (he/him)]

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).

Comment 13

[Karl Tomlinson (:karlt)]

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.

Comment 14

[Daniele "Mte90" Scasciafratte]

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.

Comment 16

[:Gijs (he/him)]

(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?

Comment 17

[Daniele "Mte90" Scasciafratte]

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

Comment 18

[aleixpol]

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?

Comment 19

[:Gijs (he/him)]

(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.

Comment 20

[Emilio Cobos Álvarez (:emilio)]

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.

Comment 21

[Emilio Cobos Álvarez (:emilio)]

Also the mime handler, perhaps.

Comment 22

[aleixpol]

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).

Comment 23

[Karl Tomlinson (:karlt)]

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.

Comment 24

[:Gijs (he/him)]

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?

Comment 25

[Emilio Cobos Álvarez (:emilio)]

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

Comment 26

[Graham Perrin]

See also: bug 727422, bug 893799, …

Comment 27

[Graham Perrin]

… bug 724461, …

Comment 30

[mcarans]

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

(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.

I tried using GTK_USE_PORTAL=1 and although I can see the file dialog is different, this does not resolve files in the Firefox download manager opening the wrong application (like deb files in Ark). Is there any workaround for the wrong application issue?

Comment 31

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

Can you try to set widget.use-xdg-desktop-portal.mime-handler to 1 and restart Firefox? It should load apps handles from portal.
Thanks.

Comment 32

[mcarans]

That worked for me for deb but strangely not for txt files which open in the e book reader (unlike elsewhere where they open in Kate). I can make a separate Firefox file association for txt, but it's a bit strange it's needed.

Comment 33

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

Jan, how it's portal configured for txt files? Is there any way how to get info about portal apps assignment?
Thanks.

Comment 34

[Jan Horak [:jhorak]]

It depends on the xdg-desktop-portal-kde implementation: https://github.com/KDE/xdg-desktop-portal-kde/blob/master/src/appchooserdialog.cpp#L113 I can see some remember settings, logs could help us more.

You should be able to get all log output by running:
QT_LOGGING_RULES="*.debug=true" /usr/libexec/xdg-desktop-portal-kde

In order to replace it you need to kill the xdg-desktop-portal-kde first.

Comment 35

[mcarans]

(In reply to Jan Horak [:jhorak] from comment #34)

It depends on the xdg-desktop-portal-kde implementation: https://github.com/KDE/xdg-desktop-portal-kde/blob/master/src/appchooserdialog.cpp#L113 I can see some remember settings, logs could help us more.

You should be able to get all log output by running:
QT_LOGGING_RULES="*.debug=true" /usr/libexec/xdg-desktop-portal-kde

In order to replace it you need to kill the xdg-desktop-portal-kde first.

I wasn't sure if this comment was meant for me. I tried to do as asked but don't know where to find the log output. Please elaborate if you need me to try again.

Comment 36

[Daniele "Mte90" Scasciafratte]

I think that the log will be printed in the console itself.

Comment 37

[mcarans]

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

I think that the log will be printed in the console itself.

You are right. I'm not sure what I did wrong before, but here is what was output this time when I clicked on a txt file in the Firefox Download Manager:

xdp-kde-background: GetAppState called: no parameters
xdp-kde-settings: Read called with parameters:
xdp-kde-settings: group: "org.freedesktop.appearance"
xdp-kde-settings: key: "color-scheme"
xdp-kde-background: GetAppState called: no parameters

I did it twice just to make sure. Each time, the ebook viewer loaded and the text above was logged in the console.