Tdesktop: Telegram desktop not displaying InlineQueryResultPhoto correctly

[mbasaglia]

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

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

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

[mbasaglia]

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]

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]

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]

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

[mbasaglia]

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]

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

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

[zefrof]

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]

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

[joshcoales]

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]

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]

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

[ReinhardtJ]

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

[gregorius90]

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]

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]

@AlexMercier Thanks! I’ll look into that.

[john-preston]

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

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

[john-preston]

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

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]

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]

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

[AlexMercier]

@mbasaglia you pass photo_widthand photo_heightfields?
also when you sending sizes you must pass thumb_url parameter

[mbasaglia]

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]

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

[Aokromes]

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

[asundukov]

it depends. Because these paramteres marked in documentation https://core.telegram.org/bots/api#inlinequeryresultphoto as _Optional_ , but without them tdesktop cannot show these items. So need to change documentation _or_ fix bug in tdesktop

[stale[bot]]

Hey there!

This issue will be automatically closed in 7 days if there would be no 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]

I don't think it has been fixed

[joshcoales]

So, apparently this problem doesn't happen if you use mtproto for the bot giving inline responses. So it's purely an interaction between the bot/web api and the telegram desktop client. Handy context to know, and a good way to avoid the issue for bot writers

[Kyle2142]

So, apparently this problem doesn't happen if you use mtproto for the bot giving inline responses. So it's purely an interaction between the bot/web api and the telegram desktop client. Handy context to know, and a good way to avoid the issue for bot writers

https://github.com/telegramdesktop/tdesktop/issues/4580#issuecomment-508954213
My bot uses mtproto

EDIT: it seems to work now. Definitely didn't a few months ago
EDIT 2: does NOT always work. :(