196481 2019-04-01 20:36:47 -0700 Caret shows in the wrong location in RTL text fields 2023-07-27 12:33:16 -0700 1 1 1 Unclassified WebKit HTML Editing WebKit Nightly Build Unspecified Unspecified NEW InRadar P2 Normal --- 1 simon.fraser webkit-unassigned ahmad.saleem792 dbates mitz rniwa simon.fraser webkit-bug-importer wenson_hsieh oldest_to_newest 1523206 0 366466 simon.fraser 2019-04-01 20:36:47 -0700 Created attachment 366466 Testcase Load the attached testcase, click in the input, and type the letter 'a'. Note how the caret stays on the left side. Now type 'b' Note how the letter was input on the right side, which is not where the caret shows. 1523207 1 webkit-bug-importer 2019-04-01 20:38:10 -0700 <rdar://problem/49507145> 1523209 2 simon.fraser 2019-04-01 20:38:38 -0700 Also, if you hit Command-Right arrow to move the caret to the end, and type, the text is inserted on the left side. 1523212 3 rniwa 2019-04-01 20:49:23 -0700 This is expected. We show the caret at where the next character whose directionality match that of the block direction. 1523213 4 simon.fraser 2019-04-01 20:51:54 -0700 The behavior doesn't make sense, and doesn't agree with Firefox. If I type a character, I expect it to get inserted where the caret is. 1523214 5 simon.fraser 2019-04-01 20:54:38 -0700 It also doesn't match native text fields in RTL. 1523215 6 rniwa 2019-04-01 20:55:50 -0700 (In reply to Simon Fraser (smfr) from comment #5) > It also doesn't match native text fields in RTL. Yeah, indeed. It looks like NSTextView has changed its behavior at some point in the past. Note that Firefox's behavior is irrelevant here because each browser implements its own bidi behavior in this regard, and we really want to match the platform convention. 1523216 7 simon.fraser 2019-04-01 20:56:39 -0700 Oh, I guess the difference is whether I'm actually entering characters in an RTL language. If I type Hebrew, it works as expected. If I type English, it does not. 1523217 8 simon.fraser 2019-04-01 20:59:11 -0700 Typing "1234" and moving the caret around shows that we don't match the OS. 1523218 9 rniwa 2019-04-01 20:59:22 -0700 (In reply to Simon Fraser (smfr) from comment #7) > Oh, I guess the difference is whether I'm actually entering characters in an > RTL language. If I type Hebrew, it works as expected. If I type English, it > does not. Yeah, it looks like NSTextView decides the caret location based on the last character being typed. Implementing the new NSTextView behavior is going to be a massive undertaking. 1523219 10 rniwa 2019-04-01 21:01:04 -0700 (In reply to Simon Fraser (smfr) from comment #8) > Typing "1234" and moving the caret around shows that we don't match the OS. Numbers are tricky because they're weakly LTR. Try typing numbers after Hebrew / Arabic. 1968497 11 ahmad.saleem792 2023-07-27 12:33:16 -0700 This is reproducible in WebKit ToT (266363@main) and Chrome Canary 117 as well. Only Firefox Nightly 117 show 'caret' properly on the right side while typing. 366466 2019-04-01 20:36:47 -0700 2019-04-01 20:36:47 -0700 Testcase just-a-text-input.html text/html 217 simon.fraser PCFET0NUWVBFIGh0bWw+Cgo8aHRtbD4KPGhlYWQ+CiAgICA8c3R5bGU+CiAgICAgICAgaW5wdXQg ewogICAgICAgICAgICBtYXJnaW46IDEwMHB4OwogICAgICAgICAgICBmb250LXNpemU6IDI0cHQ7 CiAgICAgICAgICAgIGRpcmVjdGlvbjogcnRsOwogICAgICAgIH0KICAgIDwvc3R5bGU+CjwvaGVh ZD4KPGJvZHk+CjxpbnB1dCB0eXBlPSJ0ZXh0Ij4KPC9ib2R5Pgo8L2h0bWw+Cg==