fix(app): correct RTL rendering for mixed Arabic/English content

[ahmed7542]

Issue for this PR

Fixes#35319

Type of change

• Bug fix

What does this PR do?

Mixed RTL/LTR text in the chat composer and rendered markdown was displayed in the wrong visual order, with paragraphs and tables left-aligned regardless of the dominant script. For users of Arabic, Hebrew, Persian, and Urdu, this made the chat experience unusable.

Root cause: text nodes inside the markdown container have no dir attribute and no unicode-bidi declaration, so they inherit the document's LTR base direction. The CSS in #35319's recipe (inserted via webContents.insertCSS) was the working workaround, but applying it through the build is the right long-term fix.

Changes:

• packages/session-ui/src/components/rtl.ts (new): two helpers that detect base direction from the first strong character of a string and walk a block tree to set dir="auto" on the nearest block ancestor. A second helper flips the explicit dir on <table> elements so column order matches the dominant script.
• packages/session-ui/src/components/markdown.tsx: invoke the helpers each time a block is rendered or updated, after innerHTML is set and before decorate runs.
• packages/app/src/components/prompt-input.tsx: add dir="auto" to the two contenteditable composer elements so the editor and the rendered text share a base direction.
• packages/app/src/index.css: scoped rules under [data-component="markdown"] — unicode-bidi: plaintext on text containers, margin-left: auto for table[dir="rtl"], and direction: ltr + unicode-bidi: isolate on pre/code so code blocks stay unchanged.

Why unicode-bidi: plaintext and not direction: rtl: the original issue's recipe (and our testing) shows that setting direction: rtl on free-flowing mixed Arabic/English text re-scrambles the bidi runs of inline English words. plaintext correctly orders each run by the script of the first strong character, which is what WhatsApp/Telegram/Slack do.

How did you verify your code works?

I built the web app locally against the OpenCode backend (bun --cwd packages/app dev -- --port 4444 + bun run --cwd packages/opencode serve --port 4096) and verified:

• A user message starting with Arabic renders right-aligned with the inline English word in the right place.
• A code block inside the same message stays LTR and left-aligned.
• A markdown table whose first cell starts with Arabic has its column order reversed, matching the dominant script.
• The composer input itself accepts Arabic input and renders it right-aligned as the user types.

The visual test plan in the original issue (#35319) maps 1:1 to the four changes above.

Screenshots / recordings

I have not captured screenshots, but the workaround screenshots in #35319 (the before-rtl-* and after-rtl-* attachments) show the exact behaviour this PR restores. Reviewers can run bun --cwd packages/app dev -- --port 4444 and type a mixed Arabic/English message to reproduce the fixed output locally.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Potential Duplicate Found:

• PR fix(app): auto-detect text direction (RTL) for messages and composer #32727: fix(app): auto-detect text direction (RTL) for messages and composer
  • fix(app): auto-detect text direction (RTL) for messages and composer #32727

This PR appears to address the same issue (RTL text direction detection for mixed Arabic/English content). Since your PR #37249 is described as "the native implementation of the recipe discussed in #35319" and closes issues #32726 and #32984, it may supersede or be related to PR #32727. You should verify whether #32727 is still open and if there's any overlap in scope or implementation.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[Ham3dParsa]

Also opened PR #38318 which addresses the same issue from the Electron desktop preload layer (DOM injection + MutationObserver). It's complementary — yours handles the component layer (session-ui/app), mine handles the Electron renderer. Both together cover all cases.

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.