Summary: | mimeapps.list entries containing spaces are not interpreted properly | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kservice | Reporter: | Chandradeep Dey <kde> |
Component: | general | Assignee: | David Faure <faure> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | a.samirh78, bizyaev, kdelibs-bugs, nate, spleefer90 |
Priority: | NOR | ||
Version: | 5.79.0 | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | ~/.local/share/applications/userapp-Telegram Desktop-MDCG50.desktop |
Description
Chandradeep Dey
2021-03-13 17:18:14 UTC
Oh and WORKAROUNDS 1. Escaping the space character 2. Quoting the entire string This can be tested more directly with kde-open5, which is what xdg-open calls on KDE. % kde-open5 jitsi://test Unknown protocol jitsi The generic function of xdg-open can open .desktop files with spaces without an issue. I tested this by changing firefox.desktop to fire fox.desktop, set that as the default for x-scheme-handler/https and then: kde-open5 https://kde.org opened that site in firefox as usual. Try with something that isn't http/https, Plasma handles that on its own and doesn't respect the mimeapps.list Retested, still an issue. KDE Plasma Version: 5.22.4 KDE Frameworks Version: 5.85.0 How does plasma factor in this if I used kde-open5? Also AFAIK, all KDE code uses mimeapps.list one way or the other... (In reply to Ahmad Samir from comment #3) > I tested this by changing firefox.desktop to fire fox.desktop, set that as > the default for x-scheme-handler/https and then: > kde-open5 https://kde.org > > opened that site in firefox as usual. (In reply to Ahmad Samir from comment #5) > How does plasma factor in this if I used kde-open5? > > Also AFAIK, all KDE code uses mimeapps.list one way or the other... ¯\_(ツ)_/¯ comment #1 works for Telegram though Marking this as confirmed, as it affects multiple (many) users. I tested again with element (matrix client, since that's what I have on disk), renamed the .desktop file to 'elem ent.desktop' x-scheme-handler/element=elem ent.desktop and it seems to work. Any other clues how to reproduce this issue? Created attachment 143037 [details]
~/.local/share/applications/userapp-Telegram Desktop-MDCG50.desktop
I think both me and Chandradeep misunderstood the issue.
Us adding quotes around the entry as a workaround simply broke the home desktop file, and system default was used.
The difference between the desktop entry generated in home and the system one is simple - system .desktop entry has a defined MimeType:
MimeType=x-scheme-handler/tg;
Thus the issue actually is that kde-open5 ignores the MimeType defined in mimeapps.list, and it just so happens that both .desktop entries with space on my system are the ones which have it missing.
Adding MimeType line to the .desktop entry makes it work.
If MimeType is not defined in the .desktop file, it should take the value from mimeapps.list
Attachment:
~/.local/share/applications/userapp-Telegram Desktop-MDCG50.desktop
Content of ~/.config/mimeapps.list:
[Default Applications]
x-scheme-handler/tg=userapp-Telegram Desktop-MDCG50.desktop
Reproduce:
kde-open5 tg://t.me/archlinuxgroup
That is an issue caused by a broken .desktop file. If that file was created by KDE code, we can look into fixing how the file is created. I disagree with this being a case of a broken desktop file, the mimetype is already defined in mimeapps.list, there should be no need to redefine it in the desktop file. If you hardcode xdg-open to use the generic path instead of kde-open5, it will work. Replacing "DE=kde" with "DE=generic" in /usr/bin/xdg-open will do this. Then xdg-open tg://t.me/archlinuxgroup will work, whereas kde-open5 tg://t.me/archlinuxgroup will fail. If xdg-open didn't forward the request to kde-open5, it would have worked fine. Quoting https://specifications.freedesktop.org/mime-apps-spec/mime-apps-spec-latest.html : * Adding and removing associations between mimetypes and applications is done with the following syntax in the mimeapps.list file: [Added Associations] and, in the section "Default Application" * Note as well that the default application for a given type must be an application that is associated with the type. This means that implementations should either ensure that such an association exists or add one explicitly when setting an application as the default for a type. What is described here breaks that last point, IIUC. The fact that it works with other implementations is irrelevant. This is what specs are for. (In reply to David Faure from comment #12) > Quoting > https://specifications.freedesktop.org/mime-apps-spec/mime-apps-spec-latest. > html : > > * Adding and removing associations between mimetypes and applications is > done with the following syntax in the mimeapps.list file: > [Added Associations] > > and, in the section "Default Application" > > * Note as well that the default application for a given type must be an > application that is associated with the type. This means that > implementations should either ensure that such an association exists or add > one explicitly when setting an application as the default for a type. > > What is described here breaks that last point, IIUC. > The fact that it works with other implementations is irrelevant. This is > what specs are for. I don't see why it would break the spec. In the paragraph you posted, "add one explicitly" is precisely what the [Added Associations] section is for. In fact, in the spec link you posted they have (emphasis mine)--- > The [Added Associations] group defines additional associations of applications with mimetypes, *as if the .desktop file was listing this mimetype in the first place.* Your interpretation does not allow for things such as setting a text editor as a default for a file it does not advertise compatibility with, which I find to be absurd. Having said that, I just added application/vnd.openxmlformats-officedocument.spreadsheetml.sheet=okularApplication_pdf.desktop to the [Default Applications] section without adding an entry in [Added Associations], or in okularApplication_pdf.desktop. kde-open5 and xdg-open both opened excel files using Okular afterwards, though Okular could not find a backend for the file. Yes the spec allows using [Added Associations] for that, that's exactly my point. Comment 9 only mentions the [Default Applications] section, which is not enough according to the spec. I *think* your last comment means it actually works (by chance) for normal mimetypes, just not for the x-scheme-handler special case? (In reply to David Faure from comment #15) > Comment 9 only mentions the [Default Applications] section, which is not > enough according to the spec. Oh, right. Telegram actually adds entries to both [Added Associations] and [Default Applications] > I *think* your last comment means it actually works (by chance) for normal > mimetypes, just not for the x-scheme-handler special case? Yes, but I only posted that because I thought you were saying that .desktop files needed to have every mime type specified. *** This bug has been marked as a duplicate of bug 439132 *** |