Bug 196481 - Caret shows in the wrong location in RTL text fields
Summary: Caret shows in the wrong location in RTL text fields
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-04-01 20:36 PDT by Simon Fraser (smfr)
Modified: 2019-04-01 22:22 PDT (History)
6 users (show)

See Also:


Attachments
Testcase (217 bytes, text/html)
2019-04-01 20:36 PDT, Simon Fraser (smfr)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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.