[IntersectionObserver] Fix occlusion detection with 3D transform#59807
Merged
Conversation
For regular (i.e. event-targeting) hit testing, z-axis ordering is based on the z-axis position of the center of a PaintLayer. That's not good enough for occlusion testing. With this CL, when a hit test for occlusion encounters a 3d transform, it computes the z-axis position of the four corners of the PaintLayer, and if any of them are above any point in the occlusion target (i.e. the HitTestRequest::stop_node_) then the PaintLayer is considered occluding. This is not 100% accurate, but it will never result in a false positive (i.e., reporting the target as unoccluded when it actually is), which is a hard requirement of IntersectionObserver. The corner-checking code makes a simplifying assumption that the stop_node_ has no 3D projection, which is enforced by a call to LayoutObject::HasDistortingVisualEffects from IntersectionObserver. Bug: 479203484 Change-Id: Ida70f919efc73149d32112900b019987f27a5a7e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7835432 Reviewed-by: Philip Rogers <pdr@chromium.org> Commit-Queue: Stefan Zager <szager@chromium.org> Cr-Commit-Position: refs/heads/main@{#1629048}
chromium-wpt-export-bot
force-pushed
the
chromium-export-cl-7835432
branch
from
aab7d6b to
00a4d72
Compare
wpt-pr-bot
approved these changes
May 12, 2026
Collaborator
wpt-pr-bot
left a comment
wpt-pr-bot
left a comment
There was a problem hiding this comment.
The review process for this patch is being conducted in the Chromium project.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For regular (i.e. event-targeting) hit testing, z-axis ordering is
based on the z-axis position of the center of a PaintLayer. That's
not good enough for occlusion testing.
With this CL, when a hit test for occlusion encounters a 3d transform,
it computes the z-axis position of the four corners of the PaintLayer,
and if any of them are above any point in the occlusion target (i.e.
the HitTestRequest::stop_node_) then the PaintLayer is considered
occluding. This is not 100% accurate, but it will never result in a
false positive (i.e., reporting the target as unoccluded when it
actually is), which is a hard requirement of IntersectionObserver.
The corner-checking code makes a simplifying assumption that the
stop_node_ has no 3D projection, which is enforced by a call to
LayoutObject::HasDistortingVisualEffects from IntersectionObserver.
Bug: 479203484
Change-Id: Ida70f919efc73149d32112900b019987f27a5a7e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7835432
Reviewed-by: Philip Rogers <pdr@chromium.org>
Commit-Queue: Stefan Zager <szager@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1629048}