Opening t.me links from the browser isn't working on KDE

[mid-kid]

Currently, tdesktop creates a desktop file in ~/.local/share/applications. However, this desktop file lacks the MimeType=x-scheme-handler/tg line, which the copy in /usr/share/applications does have, and something about that breaks KDE.

I haven't reproduced this myself, so I currently can't debug it or verify things like the contents of ~/.config/mimeapps.list, which for many desktops seems to be enough to make the file association. I might attempt to debug this in the future, if the solution can't be identified easily.

According to reports, adding the MimeType entry to the file, or removing the ~/.local/share/applications entry as a whole both fix the issue.

However, this seems to be a long-standing issue, having been reported by multiple people, see: https://bugs.gentoo.org/798420 https://www.reddit.com/r/ManjaroLinux/comments/k76cph/telegram_not_launching_from_the_browser_xdgopen/

Steps to reproduce

1. Install any distribution with KDE
2. Install telegram-desktop through the package repositories (not sure if this can be reproduced with the binary release)
3. ??? (I genuinely have no clue what triggers the creation of the ~/.local/share/applications entry)
4. Open a t.me link in firefox

Expected behaviour

Telegram should open like on any other desktop environment

Actual behaviour

According to the reddit post, a popup appears, saying "Unable to create io-slave. klauncher said: Unknown protocol 'tg'."

Configuration

Operating system: It's been reported on Gentoo KDE and Manjaro KDE, though presumably any KDE distribution applies.

Version of Telegram Desktop: 2.7.4, though reports date back to 6 months ago.

Installation source (Linux Only) distribution package

Used theme: Not applicable

[vimpostor]

I have the same problem on KDE. Maybe the space in "Telegram Desktop" could be at fault here:

xdg-mime query default x-scheme-handler/tg
userapp-Telegram Desktop-HUPUW0.desktop

# ~/.local/share/applications/userapp-Telegram\ Desktop-HUPUW0.desktop
# There is also no MimeType line for me in that file
[Desktop Entry]
Encoding=UTF-8
Version=1.0
Type=Application
NoDisplay=true
Exec=/usr/bin/telegram-desktop -workdir ~/.local/share/TelegramDesktop/ -- %u
Name=Telegram Desktop
Comment=Benutzerdefinition für Telegram Desktop

[mid-kid]

@vimpostor Have you tried removing the space, and adapting ~/.config/mimeapps.list to remove it as well? Does that solve the issue?

[vimpostor]

Nope, I replaced the space with minus and it still didn't work. I am not sure, if KDE is caching something though.

[mid-kid]

It's weird because I believe (though I haven't read the XDG specs) having an "Added Associations" entry should be enough to just work. Maybe it's a KDE bug after all.

[vimpostor]

I think I have found a helpful error message:

xdg-open 'tg://resolve?domain=durov' # this is the link from "View in Telegram" at https://t.me/durov

command= "/usr/bin/telegram-desktop -workdir ~/.local/share/TelegramDesktop/ -- %u" args= ("/usr/bin/telegram-desktop -workdir ~/.local/share/TelegramDesktop/ -- %u", "tg://resolve?domain=durov")
kf.kio.core: Protocol Class of url QUrl("tg://resolve?domain=durov") , isn't ':local', cancelling job.
Copying QUrl("tg://resolve?domain=durov")  to QUrl("file:///~/.cache/kioexec/krun/7009_0/unnamed")
kf.kio.core: couldn't create slave: "Meldung von klauncher: Unbekanntes Protokoll „tg“.\n"

Judging from the error message, it looks like the arguments are interpreted incorrectly? I am not sure, but shouldn't command just be /usr/bin/telegram-desktop and then args be the rest?

[mid-kid]

The weird thing is that this somehow works when you don't have the local desktop file. The file in /usr/share also uses %u so that isn't it either...

[vimpostor]

Yup, I just went and replaced the entire content of the local desktop file with the content from the system-wide desktop file and it didn't work. But removing the local desktop file works. So maybe this is actually a KDE bug.

[mid-kid]

Dibs on not being the one to forward the bug to kde. :sweat_smile:

[vimpostor]

Tracked at https://bugs.kde.org/show_bug.cgi?id=439132

[vimpostor]

Actually, this is a Telegram bug after all. I will look into this further tomorrow and create a PR then.

Basically, if you add MimeType=x-scheme-handler/tg; to the local desktop file and run update-desktop-database $HOME/.local/share/applications, it will work.

The relevant code is here: https://github.com/telegramdesktop/tdesktop/blob/6ad037e556790c6e3cfebc7aadf6b338e3f39ab9/Telegram/SourceFiles/platform/linux/specific_linux.cpp#L892

I will create a PR tomorrow, first I need to go sleep. :)

[vimpostor]

@ilya-fedin Why do the local and systemwide desktop files differ in the first place? Wouldn't it make more sense to reuse the system-wide desktop file in the "custom register" code and just add the -workdir ~/.local/share/TelegramDesktop/ line to the already well defined desktop file?

I think using Gio is a bit overkill, if there already is a perfectly fine hardcoded desktop file, wouldn't you agree?

[mid-kid]

Basically, if you add MimeType=x-scheme-handler/tg; to the local desktop file and run update-desktop-database $HOME/.local/share/applications, it will work.

Is that really necessary when the desktop file is in the Added Associations? I was under the impression that making a program the default for opening a file regardless of the MimeType entry was the use-case for that list.

[ilya-fedin]

Why do the local and systemwide desktop files differ in the first place?

I found that code in Firefox codebase. I love the idea of using proper APIs rather than tinkering with regexes, copying and calling these bugged xdg-* tools written in Bash.

[ilya-fedin]

If MimeType is not required by the specification, I would be prefer this to be fixed on Plasma side.

[mid-kid]

The ironic thing is that in the builds where the updater is enabled, GenerateDesktopFile is called, which does copy the proper .desktop file with MimeType entry and everything. It's just when Gio::AppInfo::create_from_commandline is called in an effort to make telegram the preferred association for x-scheme-handler/tg, that the incorrect file is generated. Do note, that firefox does this (create the userapp- entry and default association) when the user explicitly requests firefox be made the default browser on the system. I'm not sure why telegram does this at all:

• If the updater's enabled, GenerateDesktopFile creates a MimeType for tg:// links, as you take care of running update-desktop-database.
• If the updater's disabled, the same thing happens but thanks to the packaged system-wide desktop file.

In either scenario, telegram is (usually) the only thing that can handle tg:// links on the system, so no "preferred applications" need to be modified, be it through xdg-mime, glib or anything else. Personally I'd think this should be enough, as users should be allowed to pick between multiple tg:// handlers without telegram overriding it. Is this to handle multiple binary versions of telegram being installed concurrently? In that case, call set_as_default_for_type with the desktop file generated by GenerateDesktopFile when the updater's enabled. Alternatively, add_supports_type exists to make the association without making it default (though this modifies mimeapps.list instead of adding the MimeType entry to the desktop file, I still think the latter is the preferred method).

NOTE: The fact that the application doesn't run with the association/desktop file created by glib is still a KDE issue, however. That should be fixed separately, I just think the way telegram currently handles this should be re-evaluated, as well.

[vimpostor]

Unrelated question to your latest comment: Does the current state work on Gnome and is KDE the only offender?

And is the "Added Associations" even necessary? I think it would already be sufficient to have the tg handler in "Default Applications", but I am not sure. I can only find the specification for the desktop file structure, but not for the mimeapps.list structure.

[mid-kid]

@vimpostor

https://specifications.freedesktop.org/mime-apps-spec/latest/ar01s04.html

The [Added Associations] group defines additional associations of applications with mimetypes, as if the .desktop file was listing this mimetype in the first place.

The entries in [Default Applications] should also be considered to add an association between application and mimetype in the same manner.

That said, I believe it's useful to add it to Added Associations regardless, if it lacks a MimeType, in case the user changes the default.

And to answer your question, xdg-open and xdg-mime's shell implementations (the open_generic branches) currently handle this just fine on my system (although xdg-mime has trouble with the space in the name), though I haven't tried any other DE. gio open 'tg://', which would be called by xdg-open on some GNOME DEs handles this just fine as well. mimeopen doesn't handle URIs at all.

[vimpostor]

I agree. I have reopened the bug at KDE (that I incorrectly closed myself yesterday). I think it's not even the case that KDE ignores the "Added Associations", in fact it respects this entry. It is just that somehow with this specific codepath, it seems to ignore the %u in the Exec= line and thinks that kioexec needs to handle network transparency instead of Telegram itself (also read https://invent.kde.org/frameworks/kio/-/blob/c881bae5b05ed9e53c0e7ebc578a80baa50f5ec3/src/kioexec/README#L15-16 )

[mid-kid]

Interesting! That's one of the features I miss from when I used to use KDE, though I guess it can cause issues like this as well... The %u specifier is used correctly here, so the bug is KDE's. The odd part however is that it handles the %u just fine with the system-wide desktop file.

[ilya-fedin]

The ironic thing is that in the builds where the updater is enabled, GenerateDesktopFile is called, which does copy the proper .desktop file with MimeType entry and everything.

Yeah, I know, it's the most ugly part I don't know to replace with :(

It's just when Gio::AppInfo::create_from_commandline is called in an effort to make telegram the preferred association for x-scheme-handler/tg, that the incorrect file is generated.

Yeah, I know.

I'm not sure why telegram does this at all

To ensure the current instance is the default (in case the user has multiple instances). This is cross-platform tdesktop behavior.

In that case, call set_as_default_for_type with the desktop file generated by GenerateDesktopFile when the updater's enabled.

Well, I don't know how to.

[ilya-fedin]

Not to mention that I love how RegisterCustomScheme is independent from the desktop file currently, just like on other systems.

[ilya-fedin]

I thought multiple times to rework desktop file installation, so that it's installed only when something that needs it is involved in (e.g. unity taskbar counter or native notifications, just like start menu shortcut is installed on Windows by the native notification code). It's possible to do this currently since registering the scheme is independent from the desktop file, but won't be possible once changed.

[mid-kid]

Yeah, I know, it's the most ugly part I don't know to replace with :(

It honestly looks proper to me. Other programs sometimes replace the Exec= entry with something replaceable like @EXECHERE@, and have the build system generate it (or the program during runtime), but your regex works too. Installing the file by copying it into place is how it's done, nothing shameful about that.

Well, I don't know how to.

I believe you can call DesktopAppInfo::new_from_filename or something like that.

Not to mention that I love how RegisterCustomScheme is independent from the desktop file currently, just like on other systems.

Unfortunately, on linux at least, registering a "scheme" is done through desktop files... you're just creating a second one with the same mimetype association as the one already installed (albeit forcing it to be default).

If forcing it to be default is desired, I guess the current behavior is the correct one, as you can't assume the filename of the system-wide desktop file...

[ilya-fedin]

Yeah, it's desired

[p0358]

It might be worth noting that it seems to work fine with this AUR package: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=telegram-desktop-bin#n79 And with that package, Telegram also appears in the share menu in Dolphin when we right-click a file Where they do this:

    # Desktop launcher
    install -Dm644 "$srcdir/icon256.png" "$pkgdir/usr/share/pixmaps/telegram.png"
    install -Dm644 "$srcdir/$pkgname.desktop" "$pkgdir/usr/share/applications/telegramdesktop.desktop"

    # KDE5 & KDE4 protocol file
    install -d "$pkgdir/usr/share/kservices5"
    install -d "$pkgdir/usr/share/kde4/services"
    install -m644 "$srcdir/tg.protocol" "$pkgdir/usr/share/kservices5/tg.protocol"
    ln -s "/usr/share/kservices5/tg.protocol" "$pkgdir/usr/share/kde4/services"

$srcdir/tg.protocol:

[Protocol]
exec=/usr/bin/telegram-desktop -- %u
protocol=tg
input=none
output=none
helper=true
listing=false
reading=false
writing=false
makedir=false
deleting=false

$srcdir/$pkgname.desktop:

[Desktop Entry]
Encoding=UTF-8
Version=1.0
Name=Telegram Desktop
Comment=Official desktop version of Telegram messaging app
Exec=telegram-desktop -- %u
StartupWMClass=telegram-desktop
Icon=telegram
Terminal=false
Type=Application
Categories=Network;
MimeType=application/x-xdg-protocol-tg;x-scheme-handler/tg;
X-Desktop-File-Install-Version=0.22

[Marzal]

In ArchLinux with KDE using the official binary I don't have this problem. In case you need some testing.

xdg-mime query default x-scheme-handler/tg
appimagekit_d7e7c9ac1a8ead62d4f38771c0c8152f-Telegram_Desktop.desktop

cat ~/.local/share/applications/telegramdesktop.desktop.oficial

[Desktop Entry]
Version=1.0
Name=Telegram Desktop
Comment=Official desktop version of Telegram messaging app
TryExec=/home/dmc/opt/Telegram/Telegram
Exec=/home/zerowaste/opt/Telegram/Telegram -- %u
Icon=telegram
Terminal=false
StartupWMClass=TelegramDesktop
Type=Application
Categories=Chat;Network;InstantMessaging;Qt;
MimeType=x-scheme-handler/tg;
Keywords=tg;chat;im;messaging;messenger;sms;tdesktop;
X-GNOME-UsesNotifications=true

cat ~/.local/share/applications/appimagekit_d7e7c9ac1a8ead62d4f38771c0c8152f-Telegram_Desktop.desktop

[Desktop Entry]
...The same except
Exec=/home/zerowaste/opt/Telegram/Telegram -workdir /home/zerowaste/.local/share/TelegramDesktop/ -- %u
... this line

[ilya-fedin]

Well, the code is smart enough to not to create userapp shortcut if the current default handler has expected Exec value. It's frequently the case when using official binary probably.

[mid-kid]

That's fairly annoying - it means that a different desktop file will be generated if a user changes the default app for the scheme without reinstalling or upgrading the binary, further deviating behaviors... I wonder, does telegram show up twice in the menu for people like @Marzal ? If not, which one is preferred?

[ilya-fedin]

userapp* have NoDisplay=true

[mid-kid]

Ah, I missed that part.

[ilya-fedin]

it means that a different desktop file will be generated if a user changes the default app for the scheme without reinstalling or upgrading the binary, further deviating behaviors...

RegisterCustomScheme is called only in psNewVersion

[vimpostor]

I was expecting using add_supports_type() to work, but somehow it doesn't add anything to the desktop file even though it returns true. See the attached patch. Maybe one would have to call another GIO::AppInfo function to write the desktop file again, but I could not find any such function and I am assuming, that the call to set_as_default_for_type() creates the desktop file.

0001-Add-supported-MimeType-before-setting-as-default-han.patch.txt

diff --git a/Telegram/SourceFiles/platform/linux/specific_linux.cpp b/Telegram/SourceFiles/platform/linux/specific_linux.cpp
index dffb6c89c..ddb1e0344 100644
--- a/Telegram/SourceFiles/platform/linux/specific_linux.cpp
+++ b/Telegram/SourceFiles/platform/linux/specific_linux.cpp
@@ -895,6 +895,7 @@ void RegisterCustomScheme(bool force) {
            Gio::AppInfoCreateFlags::APP_INFO_CREATE_SUPPORTS_URIS);

        if (newAppInfo) {
+           newAppInfo->add_supports_type(std::string(kHandlerTypeName));
            newAppInfo->set_as_default_for_type(
                std::string(kHandlerTypeName));
        }

[mid-kid]

Nah, add_supports_type does the same thing as set_as_default_for_type except for adding it to Default Applications. Only reason I suggested it was to avoid overriding user defaults, in case the user wants a different client to handle tg:// links. In terms of opening tg:// links, both should work.

[vimpostor]

ok thx, I also tried this:

Glib::Value<std::string> g;
g.set("x-scheme-handler/tg;");
newAppInfo->set_property_value("MimeType", g);

I would think that at least set_property_value() would write properties in the desktop file, but unfortunately it doesn't. :(

[mid-kid]

The only property a DestkopAppInfo object seems to have is filename. The file is generated by this function and there's no way to make it set the MimeType key.

[ilya-fedin]

@vimpostor looks like your KDE report is a duplicate, I found https://bugs.kde.org/show_bug.cgi?id=437612

[ilya-fedin]

I remembered there was a file in old versions of tdesktop especially for KDE: https://github.com/telegramdesktop/tdesktop/blob/74942cd06ea5caaa925e15ad0c6939e871d706ca/lib/xdg/tg.protocol

Try to place it in ~/.local/share/kservices5.

[vimpostor]

I remembered there was a file in old versions of tdesktop especially for KDE: https://github.com/telegramdesktop/tdesktop/blob/74942cd06ea5caaa925e15ad0c6939e871d706ca/lib/xdg/tg.protocol

Try to place it in ~/.local/share/kservices5.

Does not change anything, though I am not sure if KDE is using old caches (I already ran kbuildsycoca5)

[ilya-fedin]

I guess the cache has nothing to do with that, but I can imagine that kio reads installed services only on login, so maybe you need to logout & login

[peanutbother]

I was able to fix the issue by removing every telegram related entry from ~/.config/mimeapps.list After removing everything worked again.

[mid-kid]

It will be re-added into mimeapps.list every so often...

[ilya-fedin]

Given that this issue was forwarded to KDE devs long time ago, there's no reason to have this issue open... @Aokromes can you close?

[EvgeniySnezhkov]

I solve issue. Replace all "tg" in x-scheme-handler/tg=userapp-Telegram Desktop-1YVX70.desktop; to t.me x-scheme-handler/t.me=userapp-Telegram Desktop-1YVX70.desktop; in ~/.config/mimeapps.list

[ilya-fedin]

Your changes will be cancelled as soon as you will get a client update. All you did is made the record incorrect thus KDE ignores it.

[EvgeniySnezhkov]

I don't give a damn about those who have long ignored the entire community. A working method has been presented and until fixed this is the only workable solution.

[ilya-fedin]

you can just remove the line, it will do the same, but without adding an incorrect entry

[EvgeniySnezhkov]

Only KDE and contributors are incorrect here. The presented ways are working.

[ilya-fedin]

The thing is replacement tg with t.me just removes the handler actually as t.me is not a protocol, but a domain that uses a https protocol. It would be more right to remove the line rather than making it incorrect.