Tdesktop: Unable to reassign tg:// protocol to tdesktop after another modern Windows client correctly registered itself

[LuKePicci]

Steps to reproduce

1. Install tdesktop and make sure tg:// links work
2. Install Unigram and choose it as default handler for tg:// protocol
3. Try to find a way to set tdesktop again as the default handler

Expected behaviour

tdesktop should appear in the list of apps capable of handling the tg:// protocol

Actual behaviour

tdesktop does not appear as a selectable choice for handling tg:// links

Configuration

Operating system:
Windows 10, also previous versions that support custom protocols handling should be affected but no third-party telegram apps available to reproduce the issue.

Version of Telegram Desktop:
<= 1.0.6

[john-preston]

@LuKePicci Perhaps you know how to register the app to that list? I would appreciate help here.

[auchri]

@john-preston

https://msdn.microsoft.com/en-us/library/aa767914(VS.85).aspx ?

[LuKePicci]

@john-preston I can search something about new ways of registering protocols starting from windows 8 on, however since the registration actually happens but gets broken this suggest me that there is more than a way to achive the same result, and the one tdesktop actually implements is not the right/best one. Maybe someone who knows how tdesktop implements this feature already may better understand whats going wrong.

[john-preston]

@auchri I register the handler like that in HKEY_CURRENT_USER\Software\Classes — I guess it is the same as HKEY_CLASSES_ROOT mentioned in the doc.

[john-preston]

@LuKePicci It is done that way: https://github.com/telegramdesktop/tdesktop/blob/686abd63b5ed1d2ba64809f909f2b58d19ec7367/Telegram/SourceFiles/pspecific_win.cpp#L809

This is done in every new installed version. As I understand this is the way to register the url handler (and it works as you said), but maybe there is some other way to add the application to some sort of list of applications who can handle it. Perhaps another app clears all others from that list? :)

[LuKePicci]

As an UWP, Unigram can expose itself as capable of handling some protocols but cannot force itself as default handler and absolutely not allowed to remove other apps associations. I'll give a look at the code you linked, anyway if you need an example of working behavior you can take any Office app and see that the list contains both desktop and UWP apps.

[john-preston]

@LuKePicci So it looks like I just need some hint about registering my app in some sort of list in addition to registering it as a tg:// url handler.

[auchri]

@john-preston Every example I found uses HKEY_CLASSES_ROOT

[john-preston]

@auchri I think it works my way the same, because HKEY_CLASSES_ROOT is a merge of HKEY_LOCAL_MACHINE\Software\Classes and HKEY_CURRENT_USER\Software\Classes — and I can't write to HKEY_LOCAL_MACHINE without admin rights, so I write to HKEY_CURRENT_USER.

More info here: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724475(v=vs.85).aspx

For example, if you try to write to HKEY_CLASSES_ROOT, in reality you can write to HKEY_LOCAL_MACHINE or to HKEY_CURRENT_USER depending on what already exists on the users system.

[LuKePicci]

HKEY_CURRENT_USER is ok, since it also appears correctly in CLASSES_ROOT also, what sounds me strange is: where is the mapping between the "tg" protocol and the regkey you also called "tg"? I have a VoIP desktop app which correctly registered itself as an handler for the tel:// protocol alongside Skype Desktop and Skype UWP, and its regkey name in HKEY_CURRENT_USER appears as "AppName.tel" while its contents is the same as yours. So either it maps the tg protocol to anything that ends with ".tg" or there must be some other place in the registry where there exists the actual mapping.

[john-preston]

@LuKePicci referring to https://msdn.microsoft.com/en-us/library/aa767914(VS.85).aspx the key there is named just "alert" for handling the "alert:" uri scheme. Nothing is said about "AppName.alert" there.

Which keys exactly are created by your app, where and with which values?

[LuKePicci]

Still searching the registry for other keys, I will tell you. Meanwhile take a look at the answer here: http://superuser.com/questions/1112229/cant-change-tel-protocol-handler-in-windows-10/1118456

[LuKePicci]

Ok, I have a bunch of apps that registered correctly under HKEY_CURRENT_USER\Software\Clients, including the VoIP client I mentioned and also Opera Neon and Songr, all following the same exact structure as in the link I sent above. I don't think it is necessary to put all this stuff under the Clients key since lots of other desktop apps replicate the same substructure in other places of the HKCU\Software tree.

[LuKePicci]

tg_assoc.reg.txt

It works. The reg file attached contains the solution. May be a good idea to better understand this functionality before submitting a raw patch.

[LuKePicci]

I did some research about that and it seems to be the correct solution, should I submit a pull request with the fix? What is currently done will remain untouched for backward compatibility with older Windows versions, but I think it's better to add those new keys even on older versions to avoid problems in the post upgrade phases. Let me know.

[auchri]

@LuKePicci

@FrayxRulez has already created a PR: #2957 Maybe you wanna review it? :)

[LuKePicci]

Wow, I didn't see it mentioned here, thank you.

[srazi]

Please close this and any other issues that were fixed.

I suggest to write about closing-issues-via-commit-messages in write-a-good-commit-message

[auchri]

@srazi I will update this section (or someone else if someone wants to create a PR) 😊