Bug 251313

Summary: Incorrect text caret placement when RTL text starts with whitespace
Product: WebKit Reporter: Ebrahim Byagowi <ebrahim>
Component: Layout and RenderingAssignee: zalan <zalan>
Status: RESOLVED FIXED    
Severity: Normal CC: bfulgham, koivisto, mmaxfield, simon.fraser, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: Safari Technology Preview   
Hardware: Unspecified   
OS: Unspecified   
URL: data:text/html;charset=utf8,<textarea%20dir=rtl%20style="font-size:%20500%">%20شسی%20شسی%20شسی%20شسی%20شسی%20شسی%20شسی%20شسی</textarea><script>document.querySelector('textarea').focus()</script>
Bug Depends on: 251414    
Bug Blocks:    
Attachments:
Description Flags
Caret
none
Patch
ews-feeder: commit-queue-
Patch
none
Patch
none
overhanging trailing space
none
[fast-cq]Patch none

Description Ebrahim Byagowi 2023-01-27 22:55:15 PST
This is a reduction of something that hits me on RTL websites and happens both in Safari 16.2 and tip of tree (5dc808f2):

Steps to reproduce:
Open
data:text/html;charset=utf8,<textarea%20dir=rtl%20style="font-size:%20500%">%20شسی%20شسی%20شسی%20شسی%20شسی%20شسی%20شسی%20شسی</textarea><script>document.querySelector('textarea').focus()</script>
(if caret didn't appear, click on the textarea, press Command+A, press the right arrow key button)

Expected:
The caret should go to right most position, start of the text in RTL.

Actual:
The caret goes after the first space, as can be seen in the attached screen cast.
Comment 1 Ebrahim Byagowi 2023-01-27 22:55:52 PST
Created attachment 464698 [details]
Caret
Comment 2 zalan 2023-01-28 06:57:46 PST
This is about incorrect hanging whitespace handling in RTL context. When the textarea's style is changed from "white-space: pre-wrap" to 'white-space: pre", it starts working fine.
Looking at the individual text run positions, the logically leading (visually trailing) whitespace on the first line is at -5px (this is logical x -5px, which essentially means whitespace is put outside the textarea).
Comment 3 Radar WebKit Bug Importer 2023-01-28 06:58:21 PST
<rdar://problem/104781435>
Comment 4 zalan 2023-01-29 09:00:12 PST
Created attachment 464742 [details]
Patch
Comment 5 Ebrahim Byagowi 2023-01-29 11:06:09 PST
> Patch

Just tested the patch and works as expected, awesome. Thanks 😊
Comment 6 zalan 2023-01-29 21:10:41 PST
(In reply to Ebrahim Byagowi from comment #5)
> > Patch
> 
> Just tested the patch and works as expected, awesome. Thanks 😊
Thank you so much! I decided to go with a more (RTL) focused approach though -will post a new patch soon (sorry about that, will use this patch as a more generic fix for pre-wrap vs. scrollable overflow under a different bug).
Comment 7 zalan 2023-01-30 07:49:51 PST
Created attachment 464751 [details]
Patch
Comment 8 Ebrahim Byagowi 2023-01-30 11:31:02 PST
Tested the new patch also and it works great, this use of C++ lambdas to contain variables needed to calculate one value is an interesting pattern I found in these fixes, hopefully I will use it somewhere I had access to a C++ codebase, and, thanks again 😊
Comment 9 zalan 2023-01-30 20:05:36 PST
(In reply to Ebrahim Byagowi from comment #8)
> Tested the new patch also and it works great, this use of C++ lambdas to
> contain variables needed to calculate one value is an interesting pattern I
> found in these fixes, hopefully I will use it somewhere I had access to a
> C++ codebase, and, thanks again 😊
I find it useful when I need to scope things for clarify (especially with this many lines of comment) but don't want to introduce a static helper function.
Comment 10 zalan 2023-02-01 14:16:42 PST
Created attachment 464805 [details]
Patch
Comment 11 Ebrahim Byagowi 2023-02-03 06:03:43 PST
Is that underline behind hanging space on svg/compositing/outermost-svg-with-border-padding.html worrisome? Apparently other browsers do that also,

data:text/html;charset=utf8,<u%20dir=rtl%20style="width:700px;display:block;font-size:%20500%;%20white-space:%20pre-wrap">%20%D8%B4%D8%B3%DB%8C%20%D8%B4%D8%B3%DB%8C%20%D8%B4%D8%B3%DB%8C%20%D8%B4%D8%B3%DB%8C%20%D8%B4%D8%B3%DB%8C%20%D8%B4%D8%B3%DB%8C%20%D8%B4%D8%B3%DB%8C%20%D8%B4%D8%B3%DB%8C</textarea><script>document.querySelector('textarea').focus()</u>
Comment 12 Ebrahim Byagowi 2023-02-03 06:48:42 PST
> Apparently other browsers do that also,

But it shouldn't happen beyond the element borders apparently, hmmm.
Comment 13 zalan 2023-02-03 20:07:06 PST
(In reply to Ebrahim Byagowi from comment #12)
> > Apparently other browsers do that also,
> 
> But it shouldn't happen beyond the element borders apparently, hmmm.
Chrome overhangs that trailing space too (see attached screenshot). going to take a look at that failing test case and land this patch shortly.
Comment 14 zalan 2023-02-03 20:07:29 PST
Created attachment 464830 [details]
overhanging trailing space
Comment 15 zalan 2023-02-03 20:21:39 PST
(this is with overflow: visible. the failing test has overflow auto/scroll. This is about whether the trailing hanging whitespace should contribute to scrollable or ink overflow -current behavior is ink, but with this patch we start contributing to scrollable overflow)
Comment 16 zalan 2023-02-04 19:37:44 PST
Created attachment 464842 [details]
[fast-cq]Patch
Comment 17 Ebrahim Byagowi 2023-02-04 23:00:54 PST
> Patch

Applied the patch on top of tip of tree (6c4c9810) and things look great, thanks 😊
Comment 18 zalan 2023-02-05 06:35:44 PST
(In reply to Ebrahim Byagowi from comment #17)
> > Patch
> 
> Applied the patch on top of tip of tree (6c4c9810) and things look great,
> thanks 😊
Thank you! Very much appreciated!
Comment 19 EWS 2023-02-05 06:38:49 PST
Committed 259868@main (f500d3412d93): <https://commits.webkit.org/259868@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 464842 [details].