Open mbasaglia opened 6 years ago
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!
.
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!
This issue is still very much unresolved and very much an annoyance.
I had this bug last year and I'm still having it now.
I submit a phone url and a thumb url over the inline query, and did not supply any dimensions.
Without changing my code, I can type a query on tdesktop and have it return an error of no results
moving over to the official telegram app on ios, the message has been drafted from the desktop client and prepared on my phone, which automatically sends the query and delivers back the desired images
in addition to this, as the query has now been cached by telegram server, further use of the same query will function on tdesktop results in it behaving as intended
5 years 🎉
u can just turn your pic into a .jpg and everything will work out fine. Good work around to try
---- Replied Message ---- | From | @.> | | Date | 07/15/2023 01:09 | | To | @.> | | Cc | @.>@.> | | Subject | Re: [telegramdesktop/tdesktop] Telegram desktop not displaying InlineQueryResultPhoto correctly (#4580) |
I had this bug last year and I'm still having it now. I submit a phone url and a thumb url over the inline query, and did not supply any dimensions. Without changing my code, I can type a query on tdesktop and have it return an error of no results
moving over to the official telegram app on ios, the message has been drafted from the desktop client and prepared on my phone, which automatically sends the query and delivers back the desired images
in addition to this, as the query has now been cached by telegram server, further use of the same query will function on tdesktop results in it behaving as intended
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
the problem rises when you have content from 3rd party which doesnt supply you the format AND/OR size
I found what is likely the problem, tdesktop uses a MTPDwebDocument when fetching inline photos that haven't been cached, or at least that what I am remembering. I'm a few drinks in at this point but when writing this the real problem is what I'm looking at.
https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/SourceFiles/ui/image/image_location_factory.cpp#L308
here we have a function that gets the size (dimensions) of the document so that an ImageLocation object can be returned with it's width and height, but it requires the vattributes from the MTPDwebDocument to have a value.
In debugging I found this to be empty
additionally, when looking at the function that returns the image dimensions from the same file
https://github.com/telegramdesktop/tdesktop/blob/dev/Telegram/SourceFiles/ui/image/image_location_factory.cpp#L18
it is looking for a specific mtpc_documentAttributeImageSize
attribute, but of course these don't exist in our empty attributes MTPVector
I don't think I can provide much more assistance on this, as any build of tdesktop takes around half an hour, so hopefully this might help in solving this issue, because without a greater understanding of the MTProto or how other clients are interacting with the data from the protocol, I would be hard pressed to solve this myself, and that's before the compile time issues if I did. Therefore I hope that this is some insightful information @john-preston
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!
ur mom is stale
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!
So if we want an issue to actually be fixed we need to have a bot comment on the ticket every 29 days? Cause that can be arranged...
(This is such an awful way of artificially keeping bug numbers down.)
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!
So if we want an issue to actually be fixed we need to have a bot comment on the ticket every 29 days? Cause that can be arranged...
(This is such an awful way of artificially keeping bug numbers down.)
it's not every 29 days instead 6 months, and the bot is needed because some times issues are fixed without remember to close linked issue.
some times issues are fixed without remember to close linked issue
I feel like once an issue has had the stale tag removed, it shouldn't be marked over and over. All this does is spam everyone who is watching the issue and risks of an issue being closed without being solved...
some times issues are fixed without remember to close linked issue
I feel like once an issue has had the stale tag removed, it shouldn't be marked over and over. All this does is spam everyone who is watching the issue and risks of an issue being closed without being solved...
and if bug is fixed tomorrow and preston forgets this ticket?
Is this reported on the telegram bug tracker also? Perhaps there would be better odds of this being fixed if reported over there
and if bug is fixed tomorrow and preston forgets this ticket?
literally the worst case scenario is: the opened issues will be 1 larger than they should for a while, until someone browsing for something to fix will find it, realize that it's been fixed already, and close it. in this case a false positive (being open while fixed) is way better than false negative (closed but not fixed).
@Lukasss93 But I'm afraid this is not related to the GET query in the URL, just about unknown image size. Do you provide (optional by docs) image size to the bot API?
OMG! Providing the images dimensions solved my blank boxes in the inline GIF query results! Thank you!!
https://t.me/ltexbot suffers from this, too. It would be cool if TDesktop could handle missing dimensions correctly.
I can confirm the bug (only on tdesktop), and can also confirm that setting both
photo_width
andphoto_height
fixes it.
@john-preston This issue was opened 6 years ago, I posted the above comment 2 years ago — the root cause was seemingly identified and yet as of today this is still relevant.
Maybe not a priority, but bumping because at this point it almost seems like a forgotten issue. Thank you.
Summary
I think recently there has been a regression that prevents photo results from inline bots from displaying correctly if photo_width and photo_height aren't provided (which are marked as optional in the API docs -- see https://core.telegram.org/bots/api#inlinequeryresultphoto). This used to work fine, and it work fine on the Android client so I believe it's a bug with the desktop client, it appears it isn't even trying to send a request to photo_url when width/height aren't given.
Steps to reproduce
Expected behaviour
Client should GET the photo_url from the results and display them
Actual behaviour
Doesn't fetch not display the result
Configuration
Operating system: Ubuntu, bug happens on different versions
Version of Telegram Desktop: 1.2.17 I think the issue was there before the latest update, but was working a couple month ago