Fix invalid clip of a sticky positioned item not attached to the root
Categories
(Core :: Web Painting, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox127 | --- | fixed |
People
(Reporter: dlrobertson, Assigned: botond)
References
Details
Attachments
(4 files)
Summary
Bug 1854010 introduced a workaround for a pre-existing issue with clipping a sticky position item that is not attached to the root.
For more details see this comment. In particular the following quote describing what seems to be causing the sticky position item to be clipped:
- Having an animation id causes us to create a ReferenceFrame WebRender display item here
- Having a reference frame causes mAffectsClipPositioning to be set here
- mAffectsClipPositioning causes us to enter this branch in ClipManager::BeginList() and change some state related to clips and ASRs, ultimately leading to the sticky item being (incorrectly) clipped out
Steps to reproduce
- Remove the workaround here.
a. This should essentially returnmFrame->PresContext()->IsRootContentDocumentCrossProcess()
b. (Optional) If testing on desktop remove theifdef
here - Navigate to the reduced testcase from bug 1854010 (https://bug1854010.bmoattachments.org/attachment.cgi?id=9356341)
- Ensure that the blue box is rendered.
Reporter | ||
Comment 1•1 year ago
|
||
On second thought this should probably be a defect. While there is a workaround in place, there is a bug in the clipping logic.
Comment 2•1 year ago
|
||
The severity field is not set for this bug.
:tnikkel, could you have a look please?
For more information, please visit BugBot documentation.
Updated•1 year ago
|
Assignee | ||
Comment 3•10 months ago
|
||
The two cases share some code, but the next patch will add extra logic
specific to the StickyFrame case, which makes it cleaner to split them.
Updated•10 months ago
|
Assignee | ||
Comment 4•10 months ago
|
||
The support is currently limited to translation transforms.
Depends on D208236
Assignee | ||
Comment 5•10 months ago
|
||
This uses the support added in the previous patch to set an animation property
on a StickyFrame spatial node directly.
Depends on D208237
Assignee | ||
Comment 6•10 months ago
|
||
We still limit it to Android with dynamic toolbar enabled, which is
all we currently use it for.
Depends on D208238
Assignee | ||
Comment 7•10 months ago
|
||
Try push shows a bunch of dynamic-toolbar-sticky-*
tests failing on Android, we'll need to investigate that before the patch series can land.
Assignee | ||
Comment 8•10 months ago
|
||
(In reply to Botond Ballo [:botond] from comment #7)
Try push shows a bunch of
dynamic-toolbar-sticky-*
tests failing on Android, we'll need to investigate that before the patch series can land.
Should be fixed in updated patches, new Try push at https://treeherder.mozilla.org/jobs?repo=try&revision=944de5813a28ea49289b5fb064d7f7b62c06822e
Assignee | ||
Comment 11•10 months ago
|
||
The failing job is webrender-cargotest-macos-build
, and it's failing with:
error[E0063]: missing field `transform` in initializer of `StickyFrameInfo`
--> webrender/src/spatial_tree.rs:2062:9
|
2062 | StickyFrameInfo {
| ^^^^^^^^^^^^^^^ missing `transform`
I guess that job wasn't included in any of our Try pushes so far.
Comment 12•10 months ago
|
||
That's a bit of a weird job because even with mach try chooser --full you cannot select that job. try fuzzy can find it though.
Comment 13•10 months ago
|
||
Comment 14•10 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/902352eef221
https://hg.mozilla.org/mozilla-central/rev/04fe90830b82
https://hg.mozilla.org/mozilla-central/rev/1d04a25e3326
https://hg.mozilla.org/mozilla-central/rev/78f216153c06
Description
•