-
Notifications
You must be signed in to change notification settings - Fork 658
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-masking] Behavior of clip
on position:fixed descendants is unspecified
#8336
Labels
Comments
webkit-early-warning-system
pushed a commit
to smfr/WebKit
that referenced
this issue
Jan 21, 2023
…tters on scrolling (affects Libby app) https://bugs.webkit.org/show_bug.cgi?id=250652 rdar://104095908 Reviewed by Alan Baradlay. The Libby app has content which uses a stacking-context overflow:scroll with a position:fixed descendant, and a CSS transform on an ancestor of the scroller. In this situation, we treat the position:fixed as if it has position:absolute, but still need to use the correct containing block for it (which is the enclosing transformed box). Two fixes are required here. First, `RenderLayerCompositor::computeCoordinatedPositioningForLayer()` needs to check if the position:fixed layer actually has fixed behavior (i.e. no transformed ancestor) before the early return. Second, the `traverseAncestorLayers()` helper only handled position:absolute containing block logic; we need to fix it to also compute the correct containing block for position:fixed (which allows it to find transformed ancestors of fixed). Fixing `traverseAncestorLayers()` to have the correct containingBlock behavior for fixed layers revealed a surprising behavior, which is that the deprecated CSS `clip` property on a position:absolute element clips position:fixed descendants, which is odd because it's different from how overflow works (w3c/csswg-drafts#8336). So RenderLayerCompositor::computeAncestorClippingStack() needs some special case code to detect this case. This is tested by imported/blink/fast/css/fixed-overlaps-absolute-in-clip.html. * LayoutTests/platform/ios-wk2/scrollingcoordinator/scrolling-tree/fixed-inside-stacking-overflow-inside-transformed-expected.txt: Added. * LayoutTests/scrollingcoordinator/scrolling-tree/fixed-inside-stacking-overflow-inside-transformed-expected.txt: Added. * LayoutTests/scrollingcoordinator/scrolling-tree/fixed-inside-stacking-overflow-inside-transformed.html: Added. * Source/WebCore/rendering/RenderLayerCompositor.cpp: (WebCore::traverseAncestorLayers): (WebCore::RenderLayerCompositor::computeAncestorClippingStack const): (WebCore::RenderLayerCompositor::computeCoordinatedPositioningForLayer const): Canonical link: https://commits.webkit.org/259175@main
alancoon
pushed a commit
to WebKit/WebKit
that referenced
this issue
Jan 23, 2023
A fixed header inside overflow scroll with a transformed ancestor stutters on scrolling (affects Libby app) https://bugs.webkit.org/show_bug.cgi?id=250652 rdar://104095908 Reviewed by Alan Baradlay. The Libby app has content which uses a stacking-context overflow:scroll with a position:fixed descendant, and a CSS transform on an ancestor of the scroller. In this situation, we treat the position:fixed as if it has position:absolute, but still need to use the correct containing block for it (which is the enclosing transformed box). Two fixes are required here. First, `RenderLayerCompositor::computeCoordinatedPositioningForLayer()` needs to check if the position:fixed layer actually has fixed behavior (i.e. no transformed ancestor) before the early return. Second, the `traverseAncestorLayers()` helper only handled position:absolute containing block logic; we need to fix it to also compute the correct containing block for position:fixed (which allows it to find transformed ancestors of fixed). Fixing `traverseAncestorLayers()` to have the correct containingBlock behavior for fixed layers revealed a surprising behavior, which is that the deprecated CSS `clip` property on a position:absolute element clips position:fixed descendants, which is odd because it's different from how overflow works (w3c/csswg-drafts#8336). So RenderLayerCompositor::computeAncestorClippingStack() needs some special case code to detect this case. This is tested by imported/blink/fast/css/fixed-overlaps-absolute-in-clip.html. * LayoutTests/platform/ios-wk2/scrollingcoordinator/scrolling-tree/fixed-inside-stacking-overflow-inside-transformed-expected.txt: Added. * LayoutTests/scrollingcoordinator/scrolling-tree/fixed-inside-stacking-overflow-inside-transformed-expected.txt: Added. * LayoutTests/scrollingcoordinator/scrolling-tree/fixed-inside-stacking-overflow-inside-transformed.html: Added. * Source/WebCore/rendering/RenderLayerCompositor.cpp: (WebCore::traverseAncestorLayers): (WebCore::RenderLayerCompositor::computeAncestorClippingStack const): (WebCore::RenderLayerCompositor::computeCoordinatedPositioningForLayer const): Canonical link: https://commits.webkit.org/259175@main Canonical link: https://commits.webkit.org/258608.64@safari-7615.1.18-branch
Hi @smfr, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
CSS Masking defines the (deprecated)
clip
property here: https://drafts.fxtf.org/css-masking/#clip-propertyIt notes that the property only applies to
position:absolute
elements (UAs also apply it toposition:fixed
so this could use clarification). However, the text does not say thatclip
only applies to containing-block descendants, nor doesclip
create a stacking context.Given that, I'd expect in this example that the
clip
would NOT apply to the fixedpos child:and yet all UAs agree that it does. This makes it different from the
overflow
property, which only clips containing-block descendants, and different fromclip-path
that triggers a stacking context. As an implementor, I'd prefer thatclip
isn't so special, but at least the spec should describe its implemented behavior.The text was updated successfully, but these errors were encountered: