Telegram desktop not displaying InlineQueryResultPhoto correctly #4580

mbasaglia · 2018-04-09T09:13:33Z

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

send a query to an inline bot that returns InlineQueryResultPhoto without specifying photo_width / photo_height

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

john-preston · 2018-04-09T12:21:51Z

@mbasaglia Can you provide a bot and his query for testing this?

mbasaglia · 2018-04-09T18:20:55Z

With @SomeDragonsBot foo bar my bot sends back

{"results":[{"photo_url":"https:\/\/dragon.best\/api\/some_dragons.jpg?what=foo%20bar","type":"photo","thumb_url":"https:\/\/dragon.best\/api\/some_dragons.jpg?what=foo%20bar","id":"1030832774479917668-0"}],"inline_query_id":"1030832774479917668","is_personal":"false"}

Note that after looking it on my phone it works on desktop too for that query (I assume because of caching)

mbasaglia · 2018-04-12T09:16:47Z

Now I've updated my bots to include the size to make them work on desktop, but I think this still needs to be fixed on the client side otherwise it isn't conforming to the bot API documentation.

mbasaglia · 2018-04-30T13:30:49Z

Note that even when the size is being sent, the telegram desktop client still acts weirdly:
the previews are shown, but when you click on a result to send the image, it looks much smaller than it should be (only for the person sending it).

Then it shows correctly if you restart the client.

mbasaglia · 2018-04-30T13:32:08Z

And I've also noticed the inline previews often looks weird if the image background is transparent

mbasaglia · 2018-12-19T13:16:22Z

I think there has been a regression on this, now even with width/height set the result aren't fetched/displayed on telegram desktop (only cached results are shown, even if the bot disabled caching).
On the Android client it still works as expected.

john-preston · 2018-12-24T09:01:20Z

@mbasaglia Please provide once again a bot and a query that do not work in tdesktop. Right now "@SomeDragonsBot foo bar" works fine for me.

mbasaglia · 2018-12-24T16:34:30Z

depends on caching, try a unique string as input, for example "@SomeDragonsBot hello123456" doesn't work for me

zefrof · 2019-01-25T15:58:45Z

I'd like to note I've also had this issue with my own bot. The bot is "@mtgtutorbot." Query works fine on mobile, but won't work on desktop (Win 10) if tried there first. I'm guessing it works on desktop after trying on mobile due to caching? Here are some queries I've tried:

@mtgtutorbot rakdos charm !rtr vs @mtgtutorbot rakdos charm
@mtgtutorbot path to exile !mm3 vs @mtgtutorbot path to exile

The 2nd will work every time, but the first won't work until it's been attempted on mobile.

mbasaglia · 2019-04-07T21:05:05Z

This issue still persists, even if the bot responses have the correct size and no transparency, telegram desktop shows "no results" on inline bots returning images (but works for images already queried from a different client).

SpangleLabs · 2019-06-19T20:24:28Z

An update, as I also ran into this lately:

Bunch of random results missing on Telegram desktop for windows still
Results seem to appear normally on telegram android (and plus messenger)
If you load on mobile first, then desktop, it works fine.
Doesn't seem setting the height/width makes any difference at all
I hear it's broken in MacOS also? Not sure on that.

Either way, this seems to be a bug in telegram desktop, not a bug in python-telegram-bot.
I've reported it to volunteer support, hopefully they'll log it

Kyle2142 · 2019-07-06T21:16:58Z

I would just like to chime in.
My bot https://t.me/inlinepixivbot has the same problem, where only "cached" images viewed on another client will show on tdesktop.
You can try the query "evergarden" or "Dr Stone" probably 25h after this comment. I am not quite sure what I configured the cache time as, sorry. If that fails, you're welcome to try any random words, to be honest. Most of them will have no results on tdesktop until some other client tries it
This has been happening for at least a year, up to and including the animated stickers update

Kwentar · 2020-02-24T16:33:35Z

I have the same problem, can help to reproduce if needed (only in windows desktop client)

ReinhardtJ · 2020-03-01T18:29:37Z

I can confirm this as well:
I have implemented an alternative to the @gif-Bot which uses the Tenor API instead of the Giphy one. It will always fetch 30 gif images (or as many as possible) and display them in the inline query as result.

Once you type @JonasReinhardtBot gif abc on the Desktop App (in my case Windows V1.9.14), you are not able to see all gifs appearing in the inline query result.

I debugged far enough to be able to confirm that all InlineQueryResultGifs are correctly being POSTed to the answerInlineQuery endpoint. And it also works on Telegram Web or Telegram for Android (V5.15.0)

This is the LOC where the query result is sent
https://github.com/ReinhardtJ/ReinhardtBot/blob/3a73395c0fcd559e09706b9a02255264b9ea6b85/bot/inline/gif/gif.py#L44

ghost · 2020-04-06T00:20:33Z

I can also confirm this and it is very annoying.
Only cached photos are shown on desktop, I have the same behavior as @joshcoales
Setting the cache_time parameter to 0 or a different value does not change a thing.
I'm running the windows client version 2.0.1

AlexMercier · 2020-04-18T14:34:15Z

Hello. Developer, please pay attention to this thread, coz I wrote special bot for demonstrating a bug
InlineQueryResultPhoto from bot not show big images #7654

To reproduce a bug just type inline command @TestInlineMixedBot all it will show you 4 inline items but in Desktop App you can see only 3 items, photo item will be missing due bug.
or type @TestInlineMixedBot test_url to see nothing instead of inline photo item.
Note, all this command work as expected on mobile clients, bug only in Desktop

john-preston · 2020-04-18T14:35:30Z

@AlexMercier Thanks! I’ll look into that.

john-preston · 2020-04-21T14:11:31Z

@AlexMercier Right now I can't show photo results with unknown image sizes :( I receive this:

{ botInlineResult
  flags: 54 [INT],
  id: "item_2" [STRING],
  type: "photo" [STRING],
  title: "Wow" [STRING],
  description: "Test by url" [STRING],
  url: [ SKIPPED BY BIT 3 IN FIELD flags ],
  thumb: { webDocument
    url: "..." [STRING],
    access_hash: 8512069115367755530 [LONG],
    size: 0 [INT],
    mime_type: "image/jpeg" [STRING],
    attributes: [ vector<0x0> ],
  },
  content: { webDocument
    url: "..." [STRING],
    access_hash: 2751716971740100323 [LONG],
    size: 0 [INT],
    mime_type: "image/jpeg" [STRING],
    attributes: [ vector<0x0> ],
  },
  send_message: { botInlineMessageMediaAuto
    flags: 0 [INT],
    message: "" [STRING],
    entities: [ SKIPPED BY BIT 1 IN FIELD flags ],
    reply_markup: [ SKIPPED BY BIT 2 IN FIELD flags ],
  },
},

And I look for image size attributes in those webDocument-s, I don't find them and I ignore those results :(

mbasaglia · 2020-04-21T20:21:33Z

is that size attribute the file size or the image dimensions?

john-preston · 2020-04-22T03:57:55Z

@mbasaglia The image dimension. It is marked as optional in API :( Please check if everything works fine with the valid dimensions passed to the bot api. I'll try to fix the case without dimensions, although it won't work very well in my case :(

AlexMercier · 2020-04-22T13:10:27Z

Please check if everything works fine with the valid dimensions passed to the bot api.

I checked. it work fine with heigth and width passed

AlexMercier · 2020-04-22T13:27:06Z

it won't work very well in my case

But preview image work well if bot send item with type article and thumb_url field without sizes .
you can test it @TestInlineMixedBot article_thumb

mbasaglia · 2020-04-22T13:32:48Z

For me it doesn't work even if I'm sending the size

AlexMercier · 2020-04-22T13:41:56Z

@mbasaglia you pass photo_width and photo_height fields?
also when you sending sizes you must pass thumb_url parameter

mbasaglia · 2020-04-22T13:56:09Z

This is the kind of response I give back:

{
   "results":[
      {
         "photo_url":"https:\/\/dragon.best\/api\/some_dragons.jpg?what=this%20is%20broken",
         "type":"photo",
         "thumb_url":"https:\/\/dragon.best\/api\/some_dragons.jpg?what=this%20is%20broken",
         "photo_width":512,
         "photo_height":512,
         "id":"(result id)"
      }
   ],
   "inline_query_id":"(query id)",
   "cache_time":0,
   "is_personal":false
}

but it doesn't work

asundukov · 2020-07-27T11:53:29Z

adding width and height to InlineQueryResultPhoto helps me. Now it works correctly.

Aokromes · 2020-07-27T12:22:10Z

so, it's 3rd party bug and not telegram bug?

john-preston · 2022-06-17T16:42:43Z

@Lukasss93 perhaps you can share your test bot with me (here or at https://t.me/preston) so I could debug this the same way myself.

john-preston · 2022-06-17T16:43:58Z

@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?

Lukasss93 · 2022-06-17T17:03:25Z

@Lukasss93 perhaps you can share your test bot with me (here or at https://t.me/preston) so I could debug this the same way myself.

I can't do it. This is a non-production test bot. It runs on my computer right now.

@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, it works by providing the image size!
https://via.placeholder.com/300.jpg?text=hello

Anyway, this is still a problem because I want to use another image generator and I cannot predict the image size 😥
If I try to force the image size with random values, telegram show me a non-clickable gray square...
https://example.anotherimage.generator/random-size.jpg?text=flow

EDIT:
✅ Found the "real" problem:

photo_width, photo_height fields refer to thumb_url field
the photo_url field must be an URL using port 80

Kyle2142 · 2022-06-18T00:25:45Z

It's neat and all that people are finding possible causes and/or workarounds but the fact of the matter is that the same query result loads perfectly on any other client.

Laiteux · 2022-08-30T12:59:57Z

I can confirm the bug (only on tdesktop), and can also confirm that setting both photo_width and photo_height fixes it.

RobinJ1995 · 2022-10-11T09:17:26Z

Nice find! I'd say that's definitely a bug though (as opposed to "not supported by the API") as this is a valid URL, and the mobile app supports this without any problem.

…

On Sun 12 Jun 2022, 12:15 AM Luca Patera, ***@***.***> wrote: Same issue here! Found the reason: the telegram bot API doesn't support query strings. Your image url MUST end with .jpg 😥 Example: https://via.placeholder.com/300.jpg [image: immagine] <https://user-images.githubusercontent.com/4071613/173207862-c44a9718-ad09-4194-916b-532d423bcbef.png> https://via.placeholder.com/300.jpg?text=hello [image: immagine] <https://user-images.githubusercontent.com/4071613/173207896-c06479d0-176e-4763-a523-05c2f8dd188e.png> — Reply to this email directly, view it on GitHub <#4580 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXSJF7XKROBEL4E55SK233VOUM2VANCNFSM4EZQZNEA> . You are receiving this because you commented.Message ID: ***@***.***>

ShingenPizza · 2022-10-17T15:09:32Z

hello,
i have also encountered this bug recently, and only today i realized that the bot will show me the photo results only if i have cached the specific images beforehand by linking those images directly.
i can also confirm also that the workaround method of supplying some alleged resolution also makes the images show up - even those uncached.
just as others have mentioned, the same query/result works just fine on the web and android versions. of course if you attempt it there, it will start working on desktop too, because of the images having been cached.

it's clearly a bug. please fix. (not that i believe it will be done any time soon...)

This fix is intended to mitigate a Telegram Desktop bug (telegramdesktop/tdesktop#4580) that prevents images from loading in inline query results. It also helps displaying thumbnails in the correct aspect ratio on Telegram apps on other platforms.

github-actions · 2023-04-16T01:56:45Z

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!

mbasaglia · 2023-04-16T05:59:12Z

.

RobinJ1995 · 2023-04-16T09:55:57Z

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.

Scrxtchy · 2023-07-14T16:08:52Z

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

OctoNezd · 2023-07-14T16:48:58Z

5 years 🎉

xzcxzcyy · 2023-07-17T16:37:19Z

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: ***@***.***>

OctoNezd · 2023-07-17T18:04:55Z

the problem rises when you have content from 3rd party which doesnt supply you the format AND/OR size

Scrxtchy · 2023-07-21T22:37:57Z

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

github-actions · 2024-01-18T01:47:15Z

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!

ShingenPizza · 2024-01-18T02:28:21Z

ur mom is stale

RobinJ1995 · 2024-01-18T11:46:52Z

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.)

Aokromes · 2024-01-18T12:01:40Z

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.

mbasaglia · 2024-01-18T12:41:05Z

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...

Aokromes · 2024-01-18T12:54:53Z

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?

SpangleLabs · 2024-01-18T13:13:35Z

Is this reported on the telegram bug tracker also? Perhaps there would be better odds of this being fixed if reported over there

ShingenPizza · 2024-01-18T14:15:00Z

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).

tautau · 2024-03-02T11:30:55Z

@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!!

KnorpelSenf · 2024-06-11T10:49:37Z

https://t.me/ltexbot suffers from this, too. It would be cool if TDesktop could handle missing dimensions correctly.

Aokromes added the bug label Jan 26, 2020

ilya-fedin mentioned this issue Apr 18, 2020

InlineQueryResultPhoto from bot not show big images #7654

Closed

asundukov mentioned this issue Jul 27, 2020

add width & height to inlineResultPhoto asundukov/kotlin-telegram-framework#3

Closed

github-actions bot added the stale label Apr 16, 2023

github-actions bot removed the stale label Apr 17, 2023

github-actions bot added the stale label Jan 18, 2024

github-actions bot removed the stale label Jan 19, 2024

Telegram desktop not displaying InlineQueryResultPhoto correctly #4580

Telegram desktop not displaying InlineQueryResultPhoto correctly #4580

Comments

mbasaglia commented Apr 9, 2018

Summary

Steps to reproduce

Expected behaviour

Actual behaviour

Configuration

john-preston commented Apr 9, 2018

mbasaglia commented Apr 9, 2018

mbasaglia commented Apr 12, 2018

mbasaglia commented Apr 30, 2018

mbasaglia commented Apr 30, 2018

mbasaglia commented Dec 19, 2018 • edited Loading

john-preston commented Dec 24, 2018

mbasaglia commented Dec 24, 2018 • edited Loading

zefrof commented Jan 25, 2019 • edited Loading

mbasaglia commented Apr 7, 2019

SpangleLabs commented Jun 19, 2019

Kyle2142 commented Jul 6, 2019 • edited Loading

Kwentar commented Feb 24, 2020

ReinhardtJ commented Mar 1, 2020

ghost commented Apr 6, 2020

AlexMercier commented Apr 18, 2020

john-preston commented Apr 18, 2020

john-preston commented Apr 21, 2020

mbasaglia commented Apr 21, 2020

john-preston commented Apr 22, 2020

AlexMercier commented Apr 22, 2020 • edited Loading

AlexMercier commented Apr 22, 2020 • edited Loading

mbasaglia commented Apr 22, 2020

AlexMercier commented Apr 22, 2020

mbasaglia commented Apr 22, 2020 • edited Loading

asundukov commented Jul 27, 2020

Aokromes commented Jul 27, 2020

john-preston commented Jun 17, 2022

john-preston commented Jun 17, 2022

Lukasss93 commented Jun 17, 2022 • edited Loading

Kyle2142 commented Jun 18, 2022

Laiteux commented Aug 30, 2022 • edited Loading

RobinJ1995 commented Oct 11, 2022 via email

ShingenPizza commented Oct 17, 2022

github-actions bot commented Apr 16, 2023

mbasaglia commented Apr 16, 2023

RobinJ1995 commented Apr 16, 2023

Scrxtchy commented Jul 14, 2023

OctoNezd commented Jul 14, 2023

xzcxzcyy commented Jul 17, 2023 via email

OctoNezd commented Jul 17, 2023

Scrxtchy commented Jul 21, 2023

github-actions bot commented Jan 18, 2024

ShingenPizza commented Jan 18, 2024

RobinJ1995 commented Jan 18, 2024 • edited Loading

Aokromes commented Jan 18, 2024

mbasaglia commented Jan 18, 2024

Aokromes commented Jan 18, 2024

SpangleLabs commented Jan 18, 2024

ShingenPizza commented Jan 18, 2024 • edited Loading

tautau commented Mar 2, 2024

KnorpelSenf commented Jun 11, 2024

mbasaglia commented Dec 19, 2018 •

edited

Loading

mbasaglia commented Dec 24, 2018 •

edited

Loading

zefrof commented Jan 25, 2019 •

edited

Loading

Kyle2142 commented Jul 6, 2019 •

edited

Loading

AlexMercier commented Apr 22, 2020 •

edited

Loading

AlexMercier commented Apr 22, 2020 •

edited

Loading

mbasaglia commented Apr 22, 2020 •

edited

Loading

Lukasss93 commented Jun 17, 2022 •

edited

Loading

Laiteux commented Aug 30, 2022 •

edited

Loading

RobinJ1995 commented Jan 18, 2024 •

edited

Loading

ShingenPizza commented Jan 18, 2024 •

edited

Loading