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

Wenson Hsieh
Reported 2020-06-11 09:23:22 PDT
Attachments
Patch (2.25 KB, patch)
2020-06-11 09:31 PDT, Wenson Hsieh
no flags
Patch (2.32 KB, patch)
2020-06-11 10:21 PDT, Wenson Hsieh
no flags
Wenson Hsieh
Comment 1 2020-06-11 09:31:02 PDT
Megan Gardner
Comment 2 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.
Wenson Hsieh
Comment 3 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™.
Megan Gardner
Comment 4 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.
Wenson Hsieh
Comment 5 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.
Wenson Hsieh
Comment 6 2020-06-11 10:21:23 PDT
Megan Gardner
Comment 7 2020-06-11 10:30:57 PDT
Ok, I'm sold enough then.
Wenson Hsieh
Comment 8 2020-06-11 10:31:41 PDT
Comment on attachment 401658 [details] Patch Thanks for the review!
EWS
Comment 9 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].
Note You need to log in before you can comment on or make changes to this bug.