[cheng-block]

Why

In the Canvas editor (Channel actions > View canvas > Edit), Option+Up/Down opened the previous or next channel instead of moving the caret. Option+Shift+Up/Down jumped to an unread channel instead of extending the selection.

The four stepping shortcuts run from any text field, so they work while you type a message. The dispatcher then cancels the field's own caret move. Mark conversation as read already avoids this with inFieldOutsideComposer(), but stepping never got that check.

What

The stepping shortcuts now leave the key to text fields outside the message composer.

How

• The stepping when in src/bundled/channels/index.tsx now also requires !inFieldOutsideComposer(). Terminals keep their own check.
• Every message composer's form carries data-composer-surface, so stepping from a composer is unchanged.
• docs/channels.md now names these text fields where it lists when stepping leaves the key alone.

Risk

Only the four stepping shortcuts change, and only in text fields outside the composer. Dialog fields, such as Settings, were never affected.

• In the composer, plain Option+Up/Down steps only while the draft is empty, since fix(composer): let Option+Up/Down switch conversations from an empty composer #2832. With text it moves the caret. This PR keeps that.
• fix(composer): let Option+Up/Down switch conversations from an empty composer #2832 changed the composer side. This PR was re-checked merged onto main at 8dca3d8be, and the channels, shortcuts and EditableInput tests pass.
• WIP feat(communities): open new members in a welcome channel and let admins set its welcome #2623 (still open) edits index.tsx, index.test.tsx and docs/channels.md in other places. They merge cleanly with this branch.

Testing

• The unit test runs in jsdom, which only shows the key is no longer prevented. In-app steps 1 to 3 cover WebKit's own caret move.

Screenshots

Debug build of this PR: in the Canvas editor, Option+Shift+Up selects the line "bravo" instead of switching channels.

In-app check

Verified in the macOS app by Cheng.

Build: this PR at 2e4535ecb, merged locally with my other open PRs onto main at c037057a1, run as a debug app bundle with BUZZ_DEV_VIEWER= just desktop-bundle.

Open a channel in the middle of the sidebar, with unread channels below it.

1. Open Channel actions > View canvas > Edit. Type three lines and put the caret mid-line in the second.
2. Press Option+Up, then Option+Down. The caret moves to the line's start, then end. The channel stays.
3. Press Option+Shift+Up. The text up to the line start is selected. The channel stays.
4. In the message composer, press Option+Shift+Down. The unread channel below opens, as on main.
5. In a thread's reply box, press Option+Shift+Down. An unread channel below opens, as on main.

On main, step 2 opens the previous channel. If steps 4 and 5 move the caret instead, the desktop sent the arrow as a control character. main does the same.

buzz-review-completed

[tellaho]

🤖 No must-fix design issues found in source at 2e4535ecb.

This is a contained fix for caret movement and selection in Canvas and other text fields, within the launch bug-fix policy. All four stepping shortcuts reuse the existing field guard; composer eligibility and terminal/modal handling remain intact. The regression checks field versus composer focus.

Source review only; tests inspected, not rerun. Native caret/selection and composer behavior are author-reported. No screenshots supplied; themes, widths, enlarged text, state visuals and live keyboard/focus were not independently exercised.

[tellaho]

🤖 Could you add a screenshot or short video of the change to the PR? Design uses these for faster reviews.

[cheng-block]

Could you add a screenshot or short video of the change to the PR? Design uses these for faster reviews.

Added under Screenshots in the description. They come from the debug build I tested.