End key in an RTL paragraph moves the caret to the start of the line, like Home

[Nathaniel-260]

What happened?

In a right-to-left paragraph (<w:bidi/>), the End key moves the caret to the
start of the visual line instead of its end — the same position Home gives.
In an LTR paragraph in the same document End is correct.

Expected: End moves the caret to the logical end of the visual line the caret is
on, in both directions. That is what Word does, and what SuperDoc already does in
LTR paragraphs.
Actual: in an RTL paragraph End and Home land on the same offset — the line start.

Everything else about caret motion is direction-aware, which is why this looks
like an isolated gap rather than a general RTL problem: Home, Ctrl+Home,
Ctrl+End, and the arrow keys all behave correctly in the same document
(ArrowRight moves back one logical position, ArrowLeft forward), and clicking
in the empty space past the end of an RTL line correctly places the caret at the
line's logical end. Only End is mirrored.

This is not cosmetic — it changes where text goes. A user who presses End to get
back to the end of a Hebrew sentence and types the closing full stop gets that
character as the first character of the paragraph, and in the first paragraph
that means the start of the document. That is how it was reported to us by a
user, who saw it in the saved .docx after editing.

Shift+End inherits the same behaviour and selects backwards, from the line
start to the caret, instead of from the caret to the line end.

Steps to reproduce

Minimal document — one paragraph, one run, Hebrew text, w:bidi on the paragraph:

<w:p>
  <w:pPr><w:bidi/></w:pPr>
  <w:r><w:t xml:space="preserve">משפט קצר בעברית</w:t></w:r>
</w:p>

1. Open it in SuperDoc (v2 / presentation editor).
2. Click inside the line. selection.current() reports the expected offset — for
   a click in the empty area past the end of the line it correctly reports 15,
   the logical end.
3. Press End. selection.current() now reports offset 0.
4. Type .

Exported word/document.xml:

<w:p w14:paraId="00000001">
  <w:pPr><w:bidi/></w:pPr>
  <w:r><w:t>.</w:t></w:r>
  <w:r><w:t xml:space="preserve">משפט קצר בעברית</w:t></w:r>
</w:p>

The period is a run of its own at the head of the paragraph. Word renders that
document the same way SuperDoc does, so the document really is wrong, not just
the view.

The same happens in a paragraph that wraps: with the caret in the middle of the
first visual line, End lands on the line's first offset instead of its last one,
and in the second visual line it lands on that line's first offset. In an LTR
paragraph of the same length in the same document, End lands on the end of the
visual line, as expected.

SuperDoc version

2.13.0 (@superdoc/docx-engine 0.12.0). Also reproduces on 2.12.0.

Browser

Chrome (Windows).

Additional context

Related but different, both already open: #3955 (caret painting on an empty RTL
line) and #3943 (caret painted one position back after a trailing space in RTL,
WebKit). Those are about where the caret is drawn; this one is about where the
key moves it.

For RTL-first users this is one of the more disruptive keyboard issues, because
End is the natural way to get back to the end of a sentence, and the damage lands
in the saved file rather than on screen. Thanks for the fast turnaround on the
other RTL reports — happy to test a fix against a Hebrew corpus if that helps.

[linear-code]

SD-4911

[vivienne-sd]

Appreciate the report, @Nathaniel-260 . I've reproduced this issue as well and have it documented for the team. We will keep you updated as each of these fixes land.

[Nathaniel-260]

One refinement to this report, measured today and filed separately as #3996: the sentence above saying the arrow keys "all behave correctly in the same document" holds for plain paragraphs only. In an RTL list item the horizontal arrows use the opposite model — ArrowRight moves one logical position forward, i.e. leftward on screen — and the same happens in a paragraph containing a tab, digits or Latin letters. Where a paragraph of one model meets a paragraph of the other, the caret alternates between them indefinitely and cannot cross. Sorry for the loose sentence here; #3996 has the per-combination measurement.

[caio-pizzol]

@Nathaniel-260 Thanks for the clarification — we’re tracking the arrow-key behavior separately in #3996. We’ve now also checked End and Shift+End on current V2 with wrapped RTL lines and confirmed that the issue still affects where text is inserted in the saved DOCX. We’ve narrowed down the cause and added those findings to the existing issue. We’ll update you here when a fix is available.