Bug 196481

Summary: Caret shows in the wrong location in RTL text fields
Product: WebKit Reporter: Simon Fraser (smfr) <simon.fraser>
Component: HTML EditingAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: ahmad.saleem792, dbates, mitz, rniwa, simon.fraser, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Testcase none

Description Simon Fraser (smfr) 2019-04-01 20:36:47 PDT
Created attachment 366466 [details]
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.
Comment 1 Radar WebKit Bug Importer 2019-04-01 20:38:10 PDT
<rdar://problem/49507145>
Comment 2 Simon Fraser (smfr) 2019-04-01 20:38:38 PDT
Also, if you hit Command-Right arrow to move the caret to the end, and type, the text is inserted on the left side.
Comment 3 Ryosuke Niwa 2019-04-01 20:49:23 PDT
This is expected. We show the caret at where the next character whose directionality match that of the block direction.
Comment 4 Simon Fraser (smfr) 2019-04-01 20:51:54 PDT
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.
Comment 5 Simon Fraser (smfr) 2019-04-01 20:54:38 PDT
It also doesn't match native text fields in RTL.
Comment 6 Ryosuke Niwa 2019-04-01 20:55:50 PDT
(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.
Comment 7 Simon Fraser (smfr) 2019-04-01 20:56:39 PDT
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.
Comment 8 Simon Fraser (smfr) 2019-04-01 20:59:11 PDT
Typing "1234" and moving the caret around shows that we don't match the OS.
Comment 9 Ryosuke Niwa 2019-04-01 20:59:22 PDT
(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.
Comment 10 Ryosuke Niwa 2019-04-01 21:01:04 PDT
(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.
Comment 11 Ahmad Saleem 2023-07-27 12:33:16 PDT
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.