Bug 226055 - [iOS] contextmenu hints don't follow scrolling inside `<iframe>`
Summary: [iOS] contextmenu hints don't follow scrolling inside `<iframe>`
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Devin Rousso
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-05-20 16:55 PDT by Devin Rousso
Modified: 2021-05-27 17:40 PDT (History)
5 users (show)

See Also:


Attachments
Patch (12.01 KB, patch)
2021-05-20 17:02 PDT, Devin Rousso
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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].