Bug 226055

Summary: [iOS] contextmenu hints don't follow scrolling inside `<iframe>`
Product: WebKit Reporter: Devin Rousso <hi>
Component: New BugsAssignee: Devin Rousso <hi>
Status: RESOLVED FIXED    
Severity: Normal CC: hi, simon.fraser, thorton, webkit-bug-importer, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=224204
Attachments:
Description Flags
Patch none

Description Devin Rousso 2021-05-20 16:55:56 PDT
.
Comment 1 Devin Rousso 2021-05-20 17:02:33 PDT
Created attachment 429244 [details]
Patch
Comment 2 Simon Fraser (smfr) 2021-05-20 19:59:29 PDT
Comment on attachment 429244 [details]
Patch

I'd love for us to have a generic solution to this problem that we can use for all the things that need to move with nested scrollers, like the caret, the callout bar, selection etc.
Comment 3 Devin Rousso 2021-05-21 18:24:28 PDT
(In reply to Simon Fraser (smfr) from comment #2)
> I'd love for us to have a generic solution to this problem that we can use for all the things that need to move with nested scrollers, like the caret, the callout bar, selection etc.

While I agree that a general solution would be nice, I'm not sure there is a good way to do it as each of the things you mentioned seems to have a different structure.  If you had something in mind I'd love to chat about it :)

We're able to do this for contextmenu hints because we create and own the container `UIView` and can therefore manipulate it.

Also, unlike the things you mentioned, contextmenus prevent other forms of interaction while they're presented, so this is only really necessary if the user is able to scroll while the contextmenu hint dismisses (which is possible, but requires quick reactions).
Comment 4 Tim Horton 2021-05-27 11:56:00 PDT
Comment on attachment 429244 [details]
Patch

You should sell it as "a step on the path to the generic solution" instead :)

For example, we totally do vend the view that UIKit installs the selection highlights into, so you could imagine reusing this mechanism for those (in reality I think it's possible they expect it to have the same coordinate space as WKContentView, would require some digging to see if it's directly reusable).
Comment 5 Radar WebKit Bug Importer 2021-05-27 16:56:18 PDT
<rdar://problem/78594637>
Comment 6 Devin Rousso 2021-05-27 17:10:04 PDT
(In reply to Tim Horton from comment #4)
> Comment on attachment 429244 [details]
> Patch
> 
> You should sell it as "a step on the path to the generic solution" instead :)
Oh sure!  I'm all for generic solutions :)

> For example, we totally do vend the view that UIKit installs the selection highlights into, so you could imagine reusing this mechanism for those (in reality I think it's possible they expect it to have the same coordinate space as WKContentView, would require some digging to see if it's directly reusable).
We do??!?  For my own knowledge, can you point me to where we vend the view to UIKit?
Comment 7 EWS 2021-05-27 17:40:42 PDT
Committed r278183 (238226@main): <https://commits.webkit.org/238226@main>

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