1758290 - Cannot open file with app with a desktop files specifying options in Exec=

Status: NEW

(Core :: Widget: Gtk, defect)

Description

[symphorien]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

The issue happens when opening a downloaded file with an external program that has options in the Exec= key of its desktop file (presumably only on Linux, where desktop files are used). I'll take the example of paperwork https://openpaper.work/en/

The desktop file looks like this:

[Desktop Entry]
Type=Application
GenericName=Personal Document Manager
Categories=Office;Scanning;OCR;Archiving;GNOME;
Terminal=false
Comment=Grepping dead trees the easy way
Exec=paperwork-gtk import %U
Name=Paperwork
Icon=work.openpaper.Paperwork
Keywords=document;scanner;ocr;
MimeType=application/pdf;image/bmp;image/gif;image/ico;image/icon;image/jp2;image/jpeg2000;image/jpeg;image/jpg;image/jpx;image/pjpeg;image/png;image/tiff;image/webp;image/x-bmp;image/x-MS-bmp;image/x-png;image/x-portable-bitmap;image/x-portable-graymap;image/x-portable-pixmap;image/x-tga;

Opening a pdf file with paperwork means running paperwork-gtk import file:///foo/bar/baz.pdf. Without the import verb, nothing happens.

Steps to reproduce:

1. goto https://gitlab.gnome.org/World/OpenPaperwork/paperwork-test-documents/-/raw/master/papers/20210524_2046_42/doc.pdf?inline=false
2. when the "open doc.pdf" prompt appears, choose "open with", and select "paperwork"
3. click open

Actual results:

paperwork is called as the bare executable: paperwork-gtk foo.pdf

If I check "use this app from now on", only the executable name is written in handlers.json instead of the name of the desktop file.

  "mimeTypes": {
    "application/pdf": {
      "action": 2,
      "extensions": [
        "pdf"
      ],
      "handlers": [
        {
          "name": "Paperwork",
          "path": "/home/symphorien/.nix-profile/bin/paperwork-gtk"
        }
      ]
    },

Which is all the weirder as the glib interface firefox uses works with desktop names, not executable names.

Expected results:

the desktop file is respected: paperwork-gtk import foo.pdf

Firefox remembers the app by its desktop name, not its executable path.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[Emilio Cobos Álvarez (:emilio)]

I think a potential workaround could be to use widget.use-xdg-desktop-portal.mime-handler=1 and set paperwork as your default handler for PDF system-wide. Of course not a super-convenient answer tho.

We use g_app_info_launch_uris for this (docs). The bug might be there? Our usage of the handler app stuff seems pretty reasonable: https://searchfox.org/mozilla-central/rev/990afe241fd6439817555f586c07ac1feaf79538/toolkit/system/gnome/nsGIOService.cpp#218

Comment 3

[symphorien]

Looks like createAppFromCommand https://searchfox.org/mozilla-central/source/toolkit/system/gnome/nsGIOService.cpp#664 will happily create a g_app_info with only the command and no arguments. So my hypothesis is that when firefox loads handlers.json, since it only has access to the command path, it create such a bogus app_info, and when calling it with the right function g_app_info_launch_uris the wrong command (without arguments) is executed. Firefox should probably store the value of https://docs.gtk.org/gio/method.AppInfo.get_id.html (the name of the desktop file if I understand correctly) and then when loading this value from handlers.json, enumerate all the desktop files with get_all and check which one has the right id (it does not look like there is a better API).

Comment 4

[symphorien]

As a workaround I set junction (https://apps.gnome.org/app/re.sonny.Junction/) as default handler for pdf, so that I can choose between paperwork and a normal pdf viewer.

Comment 5

[Debbie Marie]

Attachment: same problem

Thanks from diskrantamilk1985.