Group invite link sometimes does nothing for a random amount of time

[php4fan]

Steps to reproduce

1. Click on an invite link for a private group, such as https://t.me/+Rv******c0

Note that I may be clicking on such link either from Telegram Desktop itself, or on a browser. If it's on a browser, it will show the public webpage that shows the group name and says "Join group" and then will open Telegram Desktop: in that case, expected and observed behavior start from there.

Expected behaviour

Either one of these:

• immediately show me the dialog to join the group, if I'm not already a member
• immediately (or in reasonable time) open the group chat if I'm already a member
• if there's any kind of issue, show an error message accordingly
• if it's loading something, waiting for a response from a server, or in any way taking time to respond, show a spinning circle or something equivalent, and allow me to cancel.

Actual behaviour

It just did nothing.

If coming from a browser, it would bring Telegram Desktop to the foreground, with whatever chat was the last one I had interacted with, and just did nothing. It didn't show any error message.

I tried several times. Then after I gave up, I wrote a message in an unrelated group, and suddenly, out of the blue, it opened the group corresponding to the link (which is a group I had already joined), stealing focus from the one I was now writing in.

Operating system

Manjaro Linux

Version of Telegram Desktop

4.10.3

Installation source

Static binary from official website

Crash ID

No response

Logs

No response

[php4fan]

Note that in my case it was a legitimate, valid link, as I said of a group that I had already joined and which in the end worked. HOWEVER, if you try this url as is: https://t.me/+Rv******c0 with the asterisks and all, it will systematically reproduce the first part of the issue: while it should immediately show an error message saying that the link is invalid, it will instead do nothing.

[ilya-fedin]

The latest version is 4.11.1. I tell you in each report that only latest version is supported and reports with old versions are disregarded, yet you continue to report old versions.

[php4fan]

I'm sorry, I updated it like a few days ago, I don't check every minute (and it's still the latest available for Manjaro through the package system, I know that you don't care).

Test it on the latest version yourself or don't, I don't give a f***. I am the one doing you a favor by reporting an issue when I find it, not the other way around.

[ilya-fedin]

Sorry but reports about old versions aren't valuable...

[john-preston]

The invalid links, like t.me/+Rasidjf****askdfmas aren't handled in TDesktop, because they're invalid, the format isn't known to the app (because it can't be an invite link, the wrong characters are there). In case of a valid, but expired / incorrect invite link, an error is show.

[ilya-fedin]

@john-preston actual behavior suggests that the report is about a valid link but the steps to reproduce are wrong

[john-preston]

@ilya-fedin I'd say it suggests FLOOD_WAIT response without a loading indicator.

[php4fan]

The invalid links, like t.me/+Rasidjf****askdfmas aren't handled in TDesktop

If I open such a link in Chrome (one with literal asterisks), it does bring TDesktop to front.

If I click on such a link from within a chat in TDesktop, it opens it with Chrome (which is I guess what you mean when you say the link "isn't handled in TDesktop"), but hen Chrome in turn gives focus back to TDesktop.

So, in both cases, I end up with TDesktop being called and passed the link, and doing nothing. That is not correct behavior. If you are being summoned and passed a link, and you don't recognize the link as something you can or should handle, you should show an error message.

actual behavior suggests that the report is about a valid link but the steps to reproduce are wrong

The original report was about a valid link to an existing private group to that I had already joined. I'm not sure what you mean by "steps to reproduce are wrong": in that case, I obfuscated the link because I'm obviously not going to share the actual working invite link to an actual private group, I thought that was obvious (then later, I actually clicked the invalid link with the literal asterisked, and observed the wrong behavior of not showing an error message about the invalid link, and so I reported that as well).

So, regarding the valid link: In the moment I clicked that link and got the buggy behavior (i.e. TDesktop would pop up but do nothing and not show an error message), I'm not 100% sure what was my situation with respect to being able to access that particular gorup. I'm almost sure I was a member at that point, and should have been allowed to access the group; but there's a tiny chance that I had been temporarily removed or had accidentally left and later joined again and/or got readmitted (I really don't think that's the case), and/or that the admins did something during that time: meaning, there could have been a legitimate reason for not being able to access the group at that time ; but there exists no possible situation in which the behavior of doing nothing, neither opening/joining the group nor showing an error message or any message, is correct behavior.

[php4fan]

I'd say it suggests FLOOD_WAIT response without a loading indicator.

I have no idea what that is, but since you mentioned a loading indicator...

Actually in all the above mentioned cases, when TDesktop pops up and does nothing, the mouse cursor does show a bouncing animated loading icon, which goes away after a few seconds. However, it does so even when I open a valid link that works correctly, that is: I click on an invite link in Chrome; TDesktop is brought to front and the loading animation shows up, then it opens the group chat as expected, but the loading animation doesn't go away, until several seconds later (it's just a fixed time duration, regardless of whether it eventually manages to open something or not).

The reason I forgot to mention that (and I'm sorry if it is relevant) is that I get this broken loading-animation behavior with other applications too all the time, it seems to be a known bug in KDE and I've got used to completely ignoring it; and I automatically assumed that TDesktop wasn't playing any role in that.

[john-preston]

@php4fan My point is that almost all t.me links require server requests on tdesktop before showing anything. And there is no loading indicator mechanics in tdesktop while such requests are being performed. Usually it's not a problem, because the requests are quick and the action is done very fast. But in case the request is slow or if server api responds with a flood_wait error, which means that the request should be repeated after certain amount of seconds, it becomes a problem that you describes - seemingly nothing happens and them after a while suddenly something does happen.

[github-actions[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[php4fan]

The stupid bot as usual...