A <table> carrying a <caption> renders correctly and then stops passing taps to the <a href> links in the cells at its bottom. The dead band is as tall as the caption: a one-line caption costs the last row, a caption that wraps onto three lines costs the last two.
The links are present in the message — the API's echo of the parsed message shows every cell as {"type": "url", …}, caption or not — so this is hit-testing, not parsing.
Payload
Sent with sendRichMessage, as rich_message.html with skip_entity_detection: true:
<table><caption>Caption</caption>
<tr><td><a href="https://example.com/1">link 1</a></td></tr>
<tr><td><a href="https://example.org/2">link 2</a></td></tr></table>
Two rows is the minimum: a table with fewer than two rows holding content loses its links server-side, which is a different bug — telegramdesktop/tdesktop#31248.
Expected
Both links open.
Actual
link 1 opens, link 2 does not respond. Deleting the <caption> from the same payload makes both work. With a four-row table and a caption long enough to wrap onto three lines, rows 3 and 4 stop responding — the depth of the dead band tracks the caption's height.
A link in a <p> outside the table is unaffected, and the table's attributes (bordered / striped / compact) make no difference.
Environment
iPhone 14 Pro Max, iOS 26.6.1, Telegram 12.9.3. Other platforms not tested.
Possibly the same hit-testing bug as #2299 (a <tg-button> in a table cell never receives a tap).
A
<table>carrying a<caption>renders correctly and then stops passing taps to the<a href>links in the cells at its bottom. The dead band is as tall as the caption: a one-line caption costs the last row, a caption that wraps onto three lines costs the last two.The links are present in the message — the API's echo of the parsed message shows every cell as
{"type": "url", …}, caption or not — so this is hit-testing, not parsing.Payload
Sent with
sendRichMessage, asrich_message.htmlwithskip_entity_detection: true:Two rows is the minimum: a table with fewer than two rows holding content loses its links server-side, which is a different bug — telegramdesktop/tdesktop#31248.
Expected
Both links open.
Actual
link 1opens,link 2does not respond. Deleting the<caption>from the same payload makes both work. With a four-row table and a caption long enough to wrap onto three lines, rows 3 and 4 stop responding — the depth of the dead band tracks the caption's height.A link in a
<p>outside the table is unaffected, and the table's attributes (bordered/striped/compact) make no difference.Environment
iPhone 14 Pro Max, iOS 26.6.1, Telegram 12.9.3. Other platforms not tested.
Possibly the same hit-testing bug as #2299 (a
<tg-button>in a table cell never receives a tap).