49107 2010-11-05 15:58:14 -0700 In HOME/END operations, cursor goes wrong direction in mixed RTL-LTR 2025-12-26 12:40:34 -0800 1 1 1 Unclassified WebKit HTML Editing 528+ (Nightly build) All All NEW https://bug-25298-attachments.webkit.org/attachment.cgi?id=29619 InRadar P2 Normal --- 1 xji webkit-unassigned aharon ahmad.saleem792 bugs changseok fantasai.bugs mitz playmobil rniwa uriber webkit-bug-importer oldest_to_newest 305600 0 73132 xji 2010-11-05 15:58:14 -0700 Created attachment 73132 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 Actual Result: - The cursor jumps to the *beginning* of "hello" at the far left side of all the text Expected Result: - 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 305604 1 xji 2010-11-05 16:01:52 -0700 *** Bug 37884 has been marked as a duplicate of this bug. *** 320500 2 xji 2010-12-10 16:33:50 -0800 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. 2168275 3 webkit-bug-importer 2025-12-26 12:34:26 -0800 <rdar://problem/167214189> 2168276 4 fantasai.bugs 2025-12-26 12:40:34 -0800 https://bug-25298-attachments.webkit.org/attachment.cgi?id=29619 is a good testcase for this fwiw. AFAICT our implementation matches the description in https://bugs.webkit.org/show_bug.cgi?id=49107#c2 and also matches the behavior in Pages... I think that means we should close this bug as working as intended? That said, because Apple maps Home onto the Left arrow key and End onto the Right arrow key... it's a bit awkward. The left arrow goes left, except Fn+Left goes right... 73132 2010-11-05 15:58:14 -0700 2010-11-05 15:58:14 -0700 Example of mixed RTL+LTR in an RTL context home-end.html text/html 340 xji PGh0bWw+Cjxib2R5PgoKPHA+UlRMIGNvbnRleHQ8L3A+Cgo8Zm9ybT4KPGlucHV0IHR5cGU9InRl eHQiIHN0eWxlPSJkaXJlY3Rpb246IHJ0bDsiIHNpemU9IjQwIiB2YWx1ZT0iJiMxNTEzOyYjMTQ2 NDsmIzE0NzM7JiMxNTAwOyYjMTQ5MzsmIzE0NjU7JiMxNTAxO2hlbGxvIi8+CjwvZm9ybT4KCjxw PkxUUiBjb250ZXh0PC9wPgoKPGZvcm0+CjxpbnB1dCB0eXBlPSJ0ZXh0IiBzdHlsZT0iZGlyZWN0 aW9uOiBsdHI7IiBzaXplPSI0MCIgdmFsdWU9ImhlbGxvJiMxNTEzOyYjMTQ2NDsmIzE0NzM7JiMx NTAwOyYjMTQ5MzsmIzE0NjU7JiMxNTAxOyIvPgo8L2Zvcm0+CgoKPC9ib2R5Pgo8L2h0bWw+Cg==