eleven / ocho Public

ios+mac: a tapped notification lands on THAT message; the channel composer keeps the caret (#1489)

* ios: a tapped notification lands on THAT message, and the channel keeps the caret

The push route was thread-granular: the banner handed over a thread id and the
screen could only open the chat. The extension already knows the row (it
decrypts and files it into MessageStore at delivery), so it now stamps
userInfo["message"] beside the existing origin stamp — on the same
delivery-time-truth terms, and only for a real renderable feed row, so a
reaction push (no bubble of its own) is never stamped.

PushManager carries it as pendingMessageID beside pendingThreadOrigin,
routeNotificationTap arms NativeChatScreen.pendingJump — the seam a search hit
already uses — and jumpAndWave lands it: an ordinary message scrolls and waves
in the feed, a reply that lives only in its thread opens that thread and waves
inside it. The commonest tap of all is the chat ALREADY on screen (you were
reading it when the app went to the background), where nothing re-appears, so
the route posts .lchatJumpToMessage and the open screen consumes the parked
jump — with a second chance once the store catch-up folds the pushed row.

The paging walk now only pages BACK for a target that predates what's loaded: a
target newer than the newest row is the message the push just announced, still
landing, and history can never surface it — so it waits for the fold instead of
burning eight page-backs.

landOnUnreadThreadReply stays, strictly as the no-id fallback: a tap can still
arrive without a message (a push the extension couldn't decrypt, a banner in the
shade from before this build, an older server that sends no id), and for those
the all-or-nothing unread heuristic is still the only thing that finds a reply
hidden in its thread. It stands down the moment a real target is consumed.

Focus: coming back to the app with a docked thread pane open hands the caret to
the CHANNEL's composer — you return to a conversation, not to the reply you were
parked in. A handoff, never a claim: only if the pane's field actually held
focus, so a keyboard that was up moves over and one that was down stays down
(closeThread's rule). Deliberate moves into the pane are untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* mac: notification taps route to the chat AND the message; the channel bar wins on activation

The Mac tap only ever selected the space — yet its local banners already carried
the thread, and the frame carries the message id, so both were there for the
taking. They're stamped now (instance/thread/message), and the tap hands all
three to the surfaces that own each step: selection, nativeOpenThread, and
nativeJump (the search hit's path — page to the message, scroll, wave, opening
its thread when the reply lives only there).

Both requests PARK until the surface that owns them can act: the jump until its
feed is the one on screen, and the chat until its space is active with threads
in hand. The palette's open-a-chat handler became consumeOpenThread(),
re-checked when a space becomes active and once its threads have loaded, so a
tap into a space this session never opened lands as well as one into the chat
already in front of you. Reactions stay unstamped — a reaction event has no
bubble of its own to land on.

consumeJump now only pages BACK for a target that predates what's loaded: a
target newer than the newest row is the message the banner just announced, still
folding in from the socket, and history can never surface it.

Focus: MessageComposerBar's isActive was doing two jobs — "may I claim first
responder at all" and "do I take the caret when the app comes forward". Split
them. The new focusOnActivate belongs to the CHANNEL's bar whenever its space is
on screen, thread pane open or not, and is false on the pane's bar: you come
back to a conversation, not to the reply you were parked in. Opening a thread,
replying to a pane bubble, a notification landing and closeThread's hand-back
all still focus exactly as they did.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* ios+mac: pageBack waits for a message that hasn't arrived yet, instead of calling it gone

The shared jump walk answers "gone" for any target the loaded window starts
below — pages are contiguous, so a message that isn't there was deleted. That
inference only holds BELOW the window. Above it, it's a flat lie, and the
notification tap is exactly the caller that hits it: the banner names a message
this model may not have folded yet (the extension filed the row to disk at
delivery; the store catch-up or the socket's re-pull brings it in a beat later),
so a tap on the freshest possible message answered "That message isn't available
any more."

A target above the newest row now WAITS for the fold — four passes of the walk's
own budget, ~2s, then the ordinary history reasoning takes over. Measured
against the newest SERVER row, because our own unconfirmed sends carry synthetic
ids above every real one (pendingIDBase) and would otherwise make every target
look like settled history.

The walk still terminates in at most jumpPageCap passes: each one returns, waits
(bounded), or pages with its own progress check.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>