-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Group invite link sometimes does nothing for a random amount of time #27020
Comments
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. |
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. |
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. |
Sorry but reports about old versions aren't valuable... |
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. |
@john-preston actual behavior suggests that the report is about a valid link but the steps to reproduce are wrong |
@ilya-fedin I'd say it suggests FLOOD_WAIT response without a loading indicator. |
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.
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: |
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. |
@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. |
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! |
The stupid bot as usual... |
Steps to reproduce
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:
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
The text was updated successfully, but these errors were encountered: