morethanwords/tweb/master • cc42eb7 • 1 files, +8/-7
Let the link preview be dismissed back to the reply plate

Quoting a message and then typing a link left the plate stuck on the web page:
neither Escape, nor the cross, nor "Remove preview" could get rid of it.

setTopInfo({type: 'webpage'}) only repaints the plate - helperType stays
'reply' - so onHelperCancel restores the previous helper by calling
helperFunc(). But willSendWebPage was dropped only AFTER that call, and
setTopInfo bails out early on `willSendWebPage && type === 'reply'`, so the
reply was never repainted: the plate kept showing a preview that was already
gone from the state. setCurrentHover got an undefined element along the way,
which also killed the hover menu holding "Remove preview" - hence "stuck".

Drop willSendWebPage before restoring the helper; lastUrl / noWebPage are
still restored afterwards, since setTopInfo's clearHelper resets them.

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

morethanwords/tweb/master • f30c242 • 3 files, +151/-26
Offer Reopen Topic in the chat actions plate

A closed forum topic gave a manager no way back: the input stayed writable
(canSendToPeer lets canManageTopic through) but reopening was buried in the
chat-list context menu. tdesktop puts a TopicReopenBar right in the bar stack
that already carries the peer-settings actions, so the same plate carries it
here.

dialogsStorage.canReopenTopic(peerId, threadId) composes the two halves of
tdesktop's state - the topic is closed, and we may manage it - into one sync
read, so the UI asks once instead of fetching the topic and then asking about
rights.

actions plate:
- the peer-settings actions and the reopen action are now independent halves
recombined by applyButtons(), which decides the visible list (reopen first)
and the hidden state synchronously - the peer-change path keeps committing
in one go, no flicker
- the close button renders only for the peer-settings half: tdesktop's reopen
bar has no cross, and hidePeerSettingsBar would be meaningless there.
Dismissing now clears only that half, so a still-closed topic keeps its
button
- a lone button with no close beside it spans the plate (is-single) instead of
sitting in the centred pill width that reserves an end slot for the cross
- state follows the topic live: dialogs_multiupdate carries the closed flag
(it arrives as a messageActionTopicEdit service message) and chat_update
covers rights changing under us, which is what tdesktop watches
adminRightsValue for
- gated to ChatType.Chat with a thread on a chat peer, so it can't surface in
the pinned/discussion/saved views

The topic check joins the existing acked getPeerSettings call, and it answers
from worker cache, so the chat-open batch stays uncached-round-trip free.

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

#webk