| Summary: | [iOS] editing/selection/ios/update-selection-after-overflow-scroll.html times out | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Wenson Hsieh <wenson_hsieh> | ||||||
| Component: | Tools / Tests | Assignee: | 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
Wenson Hsieh
2020-06-11 09:23:22 PDT
Created attachment 401655 [details]
Patch
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. (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 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.
(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. Created attachment 401658 [details]
Patch
Ok, I'm sold enough then. Comment on attachment 401658 [details]
Patch
Thanks for the review!
Committed r262910: <https://trac.webkit.org/changeset/262910> All reviewed patches have been landed. Closing bug and clearing flags on attachment 401658 [details]. |