You need to
before you can comment on or make changes to this bug.
Created an attachment (id=73132) [details]
Example of mixed RTL+LTR in an RTL context
This is split from issue 37884.
Steps to Reproduce:
1) Make an editable RTL element with mixed RTL+LTR text in it.
e.g. <input type="text" style="direction: rtl;" size="40" value="שָׁלוֹםhello"/>
2) Put your cursor in the Hebrew text, which is correctly at the right hand beginning side of the text.
3) Press END
- The cursor jumps to the *beginning* of "hello" at the far left side of all the text
- The cursor jumps to the *end* of "hello", which is in the middle visually, between the RTL and the LTR.
- FF, IE and RTL Windows in general appear to get this right
*** Bug 37884 has been marked as a duplicate of this bug. ***
I am not sure what is the correct/expected behavior.
Following is from Aharon:
"Re the visual position after Home and End, I am not sure that there is a really "correct" way to do it. There are good reasons for either approach. BTW, Opera does it like IE, even though it has visual arrow key movements. But what WebKit and Firefox are doing is fine.".
I just read the draft specs for bidi editing by Matitiahu Allouche of IBM, the chairman of the Standards Institute of Israel's committee on IT aspects of Hebrew.
On "HOME/END" issue it says:
"Home and End keys are logical functions which move the current logical position before the first logical character (whatever its Bidi level) and after the last logical character (of the line, sentence, paragraph etc... according to whatever unit of text the non-bidi Home and End functions relate to).
The caret will be displayed on the leftmost visual position for Home in LTR paragraphs and End in RTL paragraphs, on the rightmost visual position for End in LTR paragraphs and Home in RTL paragraphs. Beside moving the caret position, Home and End must set the caret direction in accordance with the base direction of the the paragraph."
Which matches our current implementation.