Bug 213082

Summary: [iOS] editing/selection/ios/update-selection-after-overflow-scroll.html times out
Product: WebKit Reporter: Wenson Hsieh <wenson_hsieh>
Component: Tools / TestsAssignee: Wenson Hsieh <wenson_hsieh>
Status: RESOLVED FIXED    
Severity: Normal CC: bdakin, megan_gardner, thorton, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch none

Description Wenson Hsieh 2020-06-11 09:23:22 PDT
<rdar://problem/64228007>
Comment 1 Wenson Hsieh 2020-06-11 09:31:02 PDT
Created attachment 401655 [details]
Patch
Comment 2 Megan Gardner 2020-06-11 09:52:34 PDT
Is there a way you can programmatically find a point that will always be ok, even if more things change in the future? I want to suggest making another line a target and clicking the the middle of that, but there's no guarantee that the callout bar won't appear over that area.
Comment 3 Wenson Hsieh 2020-06-11 09:58:16 PDT
(In reply to Megan Gardner from comment #2)
> Is there a way you can programmatically find a point that will always be ok,
> even if more things change in the future? I want to suggest making another
> line a target and clicking the the middle of that, but there's no guarantee
> that the callout bar won't appear over that area.

I’m not sure what you mean by “making another line a target”.

If the callout bar does appear over (40, 40), then I think that would indicate a Real Bug™.
Comment 4 Megan Gardner 2020-06-11 10:09:00 PDT
Comment on attachment 401655 [details]
Patch

I mean something like:
<p id='scroll-target'>The quick brown fox jumped over the lazy dog.</p>
and 
var scrollTargetRect = document.getElementById('scroll-target').getBoundingClientRect();
await UIHelper.UIHelper.immediateScrollElementAtContentPointToOffset(scrollTargetRect.x,scrollTargetRect.y); // or do the center of the line if that makes more sense

instead of hardcoding numbers that might need to be changed.
Comment 5 Wenson Hsieh 2020-06-11 10:12:25 PDT
(In reply to Megan Gardner from comment #4)
> Comment on attachment 401655 [details]
> Patch
> 
> I mean something like:
> <p id='scroll-target'>The quick brown fox jumped over the lazy dog.</p>
> and 
> var scrollTargetRect =
> document.getElementById('scroll-target').getBoundingClientRect();
> await
> UIHelper.UIHelper.
> immediateScrollElementAtContentPointToOffset(scrollTargetRect.x,
> scrollTargetRect.y); // or do the center of the line if that makes more sense
> 
> instead of hardcoding numbers that might need to be changed.

I designed the test so that the scrollable editor area’s origin is always at (0, 0) in the document, so I chose (40, 40) to mean “an offset slightly away from the top left corner of the scrollable area“. I could use the bounding rect top/left, but I don’t think it adds much here.
Comment 6 Wenson Hsieh 2020-06-11 10:21:23 PDT
Created attachment 401658 [details]
Patch
Comment 7 Megan Gardner 2020-06-11 10:30:57 PDT
Ok, I'm sold enough then.
Comment 8 Wenson Hsieh 2020-06-11 10:31:41 PDT
Comment on attachment 401658 [details]
Patch

Thanks for the review!
Comment 9 EWS 2020-06-11 10:57:18 PDT
Committed r262910: <https://trac.webkit.org/changeset/262910>

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