Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 0825ca6fee879a88c69897d806a5d1db09b77f70
https://github.com/WebKit/WebKit/commit/0825ca6fee879a88c69897d806a5d1db09b77f70
Author: Ryosuke Niwa <[email protected]>
Date: 2026-07-27 (Mon, 27 Jul 2026)
Changed paths:
A
LayoutTests/http/tests/site-isolation/touch-events/resources/nested-ad-reports-click.html
A
LayoutTests/http/tests/site-isolation/touch-events/resources/samesite-offset-container.html
A
LayoutTests/http/tests/site-isolation/touch-events/tap-nested-cross-origin-frame-in-offset-subframe-expected.txt
A
LayoutTests/http/tests/site-isolation/touch-events/tap-nested-cross-origin-frame-in-offset-subframe.html
M Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm
Log Message:
-----------
[Site Isolation] [iOS] Tapping sometimes doesn't work when shared process is
enabled
https://bugs.webkit.org/show_bug.cgi?id=320288
rdar://179511074
Reviewed by Sihui Liu and Wenson Hsieh.
The bug was caused by a coordinate-transform bug in the iOS two-phase tap path.
When user taps on a page and the main frame's process first does hit testing.
When it lands
on a cross-origin (remote) iframe it transforms the tap into that frame's
coordinate space
and re-dispatches it to the frame's process. The transform was:
remoteFrameView->rootViewToContents(
ownerFrameView->contentsToRootView(position) )
where ownerFrameView was frameOwner->document().frame()->view() - the view of
the frame that
contains the tapped iframe element. The position is now expressed in the
hit-tested (root)
frame's coordinates, but when the cross-origin iframe is nested inside an
offset same-site
subframe, frameOwner->document().frame() is that nested subframe - not the root
frame.
Feeding a root-frame point through the nested frame's contentsToRootView
double-counts the
container's offset; rootViewToContents then subtracts it back, so the transform
nets to
identity and the tap lands outside the target frame. The remote frame's process
finds no
node there so the click is never synthesized and nothing happens.
This PR fixes the bug by in potentialTapAtPosition, transforming the point
starting from
localRootFrame's view (the frame the hit-test was performed in, whose
coordinates position
is actually in) instead of the tapped iframe owner's frame view.
RemoteFrameView::rootViewToContents already walks the full ancestor chain, so
composing it
with the root frame's contentsToRootView yields the correct point regardless of
nesting depth.
Direct-child taps are unchanged (there localRootFrame == the owner's frame).
Test:
http/tests/site-isolation/touch-events/tap-nested-cross-origin-frame-in-offset-subframe.html
*
LayoutTests/http/tests/site-isolation/touch-events/resources/nested-ad-reports-click.html:
Added.
*
LayoutTests/http/tests/site-isolation/touch-events/resources/samesite-offset-container.html:
Added.
*
LayoutTests/http/tests/site-isolation/touch-events/tap-nested-cross-origin-frame-in-offset-subframe-expected.txt:
Added.
*
LayoutTests/http/tests/site-isolation/touch-events/tap-nested-cross-origin-frame-in-offset-subframe.html:
Added.
* Source/WebKit/WebProcess/WebPage/Cocoa/WebPageCocoa.mm:
(WebKit::WebPage::potentialTapAtPosition):
Canonical link: https://commits.webkit.org/317994@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
