fix: keep typed text at the clicked point in RTL editor

[Goudarz]

Fixes #2985

In RTL translations quoted values such as HTML attribute values used dir="auto". The browser resolves that over the value while CodeMirror resolved it per segment between placeholders so arrow keys and clicks didn't match what was shown. The direction is now detected once. Set explicitly for both and it no longer flips while typing (for example adding a Persian word in front of an English one).

There is also an ambiguity that BiDi text always has: next to a boundary between English text, one point on screen maps to two positions and which one shows the typed text depends on what you type. Native editors resolve this using the keyboard language (Murray Sargent "Text Insertion Point"). We can't detect that on the web so after a click the first typed character is placed at the nearby position where it actually shows up next to the click. Its measured on before input on lines that mix directions and the trial edits don't touch the undo history.

Tested in Firefox/Edge by clicking both edges of words and typing English letters in Persian, English and mixed values in Fluent and plain strings and, in an LTR locale.

Screenshots

Before / After

[codecov-commenter]

Codecov Report

❌ Patch coverage is 34.26573% with 94 lines in your changes missing coverage. Please review.
✅ Project coverage is 84.65%. Comparing base (90890c2) to head (15adc55).

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[eemeli]

@Goudarz Hi, this looks really interesting! Before I get too deep into reviewing the code, two questions:

First, has the divergence with native/browser editors been reported upstream to CodeMirror as a bug? Its issue tracker is here, you can log in with your GitHub account. I didn't do this previously as I'd not investigated deep enough to find the root cause or a minimal reproduction (to verify that this isn't specific to our code only). It would be preferable for the dir=auto handling to get fixed for all CodeMirror users, rather than us needing to patch it in Pontoon -- though that's an option as well.

You should be able to CC me there as @eemeli, and refer to this repo's issues and PRs with their full URL.

Second, your comment above mentions

Native editors resolve this using the keyboard language (Murray Sargent "Text Insertion Point").

Is this intended as a reference to something specific? Just searching for the parenthetical text I wasn't able to find it, and I'd like to read more.

[Goudarz]

Thanks! I've now reported the dir="auto" issue upstream with a reproduction (no Pontoon code, same behavior in Firefox 155 @codemirror/view 6.43.14): https://code.haverbeke.berlin/codemirror/dev/issues/1768

This is the part that breaks arrow-key navigation. If it gets fixed in CodeMirror, then the explicit direction in decoratorPlugin.ts can be removed. The other issue—where typed text appears away from a click near a Persian/ boundary—isn't really a CodeMirror bug. Native contenteditable elements behave the way because a click at that point can map to two positions and which one is selected depends on what gets typed next.

The reference is Murray Sargents post about the text insertion point: https://learn.microsoft.com/en-us/archive/blogs/murrays/text-insertion-point (section "BiDi text insertion points"). Native editors use the keyboard language to decide where to insert text. We can't detect the keyboard language, on the web so the PR uses the typed character instead.