fix(web): Arabic and Hebrew text reads and navigates right to left#22777

Problem

On web and desktop, every block in the composer and in chat messages is laid out left to right. For anyone writing Arabic or Hebrew, which is #13622:

• Lines are left aligned, and the period jumps to the start of the sentence.
• English terms and inline code inside a line reorder the words around them. setState داخل useEffect reads backwards.
• List bullets, numbers and quote rules sit on the left, and tables keep left-to-right column order.
• Thread titles in the sidebar, the header and the command palette are cut off from the wrong end.

Typing has a second problem, which isn't mentioned in #13622 or #16839. Giving the blocks a direction isn't enough on its own. ProseMirror on Chrome reads arrow-key direction from the editor root, not from the line (findDirection in prosemirror-view 1.42.3 returns getComputedStyle(view.dom).direction). The composer's own arrow and Cmd+Arrow handling also assumes ArrowLeft means back. So in an Arabic line, ArrowRight stops at the edge of inline code and stays there however many times you press it.

To reproduce: send a message in Arabic that contains inline code, or ask an agent to answer in Arabic. Then type اكتب دالة `sumBy` تجمع القيم in the composer and walk the line with the arrow keys.

Change

Direction per block. Each top-level block (paragraph, heading, list, quote, table) takes the direction of most of its words. Each word votes by its first letter, a tie goes to the first word, and inline code doesn't vote. This keeps StrictMode: يعيد الـ render مرتين right to left, where dir="auto" would make it left to right because of its first letter. It also gets the cases raised on #16839 right:

Lines inside a list or quote follow it, so bullets, task checkboxes and quote rules stay on the same side as the text.

Code stays left to right. Code blocks are LTR. Inline code is isolated with dir="ltr", so fetch() inside Arabic no longer shows as ()fetch.

CSS. List, quote and table spacing use logical properties (padding-inline-start, border-inline-start, text-align: start), as do the GitHub alert quote's classes.

Chat messages. A small rehype plugin, chat/markdownTextDirection.ts, sits next to rehypeHeadingIds and applies the rule.

Composer. composer-text-direction.ts sets each block's direction with node decorations, so the stored draft doesn't change. Results are cached per block and per document, so a keystroke only recounts the block it changed. The extension also:

• Sets the root dir to the caret's line, so ProseMirror's arrow handling agrees with the line.
• Gives the composer's arrow-key and Cmd+Arrow handling the same direction.
• Starts an empty line in the direction of the line above, so Shift+Enter after Arabic keeps the caret on the right.
• In an RTL line, moves the opening backtick marker into the code isolate, so `sumBy` keeps a backtick on each side while you edit it. LTR lines render exactly as before.

Titles. Thread titles in the sidebar, the header and the command palette follow their own text. The rename fields use dir="auto".

Scope and approval

This addresses #13622. #16839 covers the same bug with a similar letter-majority rule and is waiting on a maintainer decision about the rule and on native mobile work (Julius's preflight). This PR is the web and desktop half only, and the keyboard fixes above apply to any per-block direction rule.

I can't claim approval for the rule. I'm asking maintainers to pick one. If #16839's rebuild is the way forward, please take whatever is useful from here; I posted the details there too.

Every change is needed for the same problem. Without the arrow and root-direction fixes, giving the blocks a direction makes composer navigation worse.

Mobile, the terminal (which draws its own canvas) and nested-table direction are not covered here.

Verification

All screenshots and the video use the same real Claude conversation, on the same isolated state, captured on main (21da306) and on this branch. I recorded them in Chromium with Playwright, because the built-in Browser panel's snapshots timed out on this machine.

Typing, arrow keys through inline code, Shift+Arrow selection and Cmd+Arrow in an Arabic line:

https://github.com/user-attachments/assets/0f8a907d-a1cd-4ef8-bea3-fac7ceb42fb6

Messages, lists, quote and title:

Code block and table (code stays LTR, table columns flip):

Composer draft with a list:

Backticks while the caret is inside inline code, with an RTL line above an unchanged LTR line:

Command palette thread titles:

Tests:

• textDirection.test.ts covers the rule (Arabic, Hebrew, English, English-led Arabic, English with a quoted Arabic word, ties, numbers and punctuation). composer-text-direction.test.ts covers inline code not voting, a list taking one direction, letterless lines continuing the line above, and code blocks staying LTR.
• Three browser tests in ComposerPromptEditorTiptap.input.browser.test.tsx use real key presses:
  • ArrowRight leaves inline code through its start in an Arabic line.
  • The backticks sit on either side of the code being edited.
  • Shift+Enter after Arabic starts on the right.
• Each browser test fails without its part of the fix. Without the root dir, the caret sticks at the code edge; without the extension, all three fail.
• vp test run on all the composer, ChatMarkdown, sidebar and command palette test files: 413 passed. vp lint on the changed files reports nothing, and vp run typecheck (apps/web) and vp run knip:check pass.

Not checked: Safari and Firefox. Their findDirection measures each position instead of reading the root's direction, so the root dir should be harmless there. I also didn't check Windows Chromium or the packaged desktop app.

Written with Claude Opus 5.5 in Claude Code (running inside T3 Code).

🤖 Generated with Claude Code