morethanwords/tweb/master • 95933b1 • 3 files, +45/-19 Show typing in a dialog row that is built whi

morethanwords/tweb/master • 95933b1 • 3 files, +45/-19
Show typing in a dialog row that is built while the peer types

The indicator lives only in the DOM, and setTyping is called from exactly one
place — the peer_typings event. A DialogElement built after the peer started
typing therefore never gets it: switching folders shows the last message instead,
since every folder owns its list and builds its own rows, and the virtual list's
re-init has the same hole. Both recover only on the next typing update.

The apply half of setTyping moves into setDialogTyping, which initDialog now
calls once the row's subtitle is rendered — chained off the returned promise
rather than into it, so a row still appears as fast as before. All four dialog
lists already went through setTyping, so they share the one implementation.

getPeerTyping now asks for the typings before asking whether the peer is a bot.
Same answer either way, but it is consulted for every row that gets built now,
so the check that says "no" for almost every peer should be the one that costs a
single worker round-trip.

Verified against a real typing state in the worker: rebuilding a row mid-typing
showed the last message before, and shows the activity after.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

morethanwords/tweb/master • ce37ebe • 1 files, +50/-12
Jump to the unread messages instead of the chat's end

The go-down button and re-clicking the open dialog in the chat list both land in
bubbles.setPeer with samePeer, where following the read cursor was gated on
!samePeer — so a chat left scrolled up with a pile of unread messages below was
always thrown to the very bottom, past all of them.

tdesktop answers this in HistoryWidget::insideJumpToEndInsteadOfToUnread with
`unread && itemTop(unread) <= visibleBottom`: go to the end only once the first
unread message is no longer below the viewport, otherwise scroll it to the top.
The gate now asks the same question, and the samePeer fast path — which had no
branch for followingUnread and so silently did nothing — scrolls to the
delimiter with position 'start'. It stays keyed on sameSearch, so leaving an
in-chat search still goes to the end as before.

The anchor is the existing firstUnreadBubble, which is tdesktop's unread bar:
frozen for as long as the chat is open, so a second press finds it on screen and
goes to the end instead of chasing the read cursor down the history a viewport
at a time. setUnreadDelimiter never attached it in a group the user administers,
though — its monoforum guard read canManageDirectMessages without isMonoforum,
and the creator of any group holds manage_direct_messages — so the divider was
missing there as well. Every other reading of that flag pairs the two.

Verified in a preview against a group with 18 real unread messages, from both
entry points: scrolled up with the delimiter far below the visible area, the
first press put it at the top of the viewport with 1753px of history still
below, and the second press landed at the very end.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

#webk