While looking at the backout, I noticed table parts relied on reframing
on abspos-container-ness changes in a subtle way, see the test, which
fails with the first patch of this bug applied without these changes.
Make the NS_FRAME_CAN_HAVE_ABSPOS_CHILDREN mean the same for table parts
as for everything else. Instead, keep the registration status on each
relevant frame class individually.
Depends on D169127
Differential Revision: https://phabricator.services.mozilla.com/D170969
While looking at the backout, I noticed table parts relied on reframing
on abspos-container-ness changes in a subtle way, see the test, which
fails with the first patch of this bug applied without these changes.
Make the NS_FRAME_CAN_HAVE_ABSPOS_CHILDREN mean the same for table parts
as for everything else. Instead, keep the registration status on each
relevant frame class individually.
Depends on D169127
Differential Revision: https://phabricator.services.mozilla.com/D170969
Teach nsDisplay{Filters,BackdropFilters} to use a style that doesn't
belong to mFrame for the root frame, and use it as needed.
Remove the BackdropFilters::CanCreateWebrenderCommands call because it
was testing for StyleSVGEffects::mFilters rather than mBackdropFilters,
so it was doing nothing.
Differential Revision: https://phabricator.services.mozilla.com/D146188
`nsIFrame::IsRelativelyPositioned()` tests "position:relative" or
"position:sticky", but its naming is misleading until you've dug into the
underlying helper `nsStyleDisplay::IsRelativelyPositionedStyle()`.
Differential Revision: https://phabricator.services.mozilla.com/D140273
Make sure it's always in sync with the style.
Keeping a boolean field was useful when we didn't handle dynamic changes
to it, but now we do it's just redundant, and could cause correctness
issues.
Differential Revision: https://phabricator.services.mozilla.com/D124081
As per https://drafts.csswg.org/css-will-change/#will-change.
> If any non-initial value of a property would cause the element to
> generate a containing block for absolutely positioned elements,
> specifying that property in will-change must cause the element to
> generate a containing block for absolutely positioned elements.
But in this case the transform property wouldn't apply to the element so
there's no reason to create a stacking-context.
Differential Revision: https://phabricator.services.mozilla.com/D114121
Also: adjust include paths to be consistent for usages of various SVG headers,
and remove unused SVG includes (mostly for "utils" classes),
and drop stray "ns" from already-renamed SVG classes in various code comments.
Differential Revision: https://phabricator.services.mozilla.com/D83140
The trickier part is that we represent -moz-image-rect as a Rect() type instead
of image with non-null clip-rect. So we need to add a bit of code to
distinguish "image request types" from other types of images.
But it's not too annoying, and we need to do the same for fancier images like
image-set and such whenever we implement it, so seems nice to get rid of
most explicit usages of nsStyleImage::GetType().
Differential Revision: https://phabricator.services.mozilla.com/D62164
--HG--
extra : moz-landing-system : lando
Storing it in the style value doesn't make much sense, specially since we store
drawing-dependent stuff there like the svg viewport size, which clearly depends
on the size of the frame.
This cache may not be very useful anymore, see the linked bug, but this unblocks
me with other style system cleanups and seems safer.
Differential Revision: https://phabricator.services.mozilla.com/D62162
--HG--
extra : moz-landing-system : lando
SVG Text stuff doesn't support abspos or anything like that, so it's not like it
is useful.
Differential Revision: https://phabricator.services.mozilla.com/D44136
--HG--
extra : moz-landing-system : lando
We could use ArcSlice if wanted I guess, your call. Though will change is not
supposed to be used very frequently.
Differential Revision: https://phabricator.services.mozilla.com/D30548
--HG--
extra : moz-landing-system : lando
After this I can pass the document from the caller to ResolveSameStructsAs, and
get rid of the pres context pointer.
Differential Revision: https://phabricator.services.mozilla.com/D18600
--HG--
extra : moz-landing-system : lando
After this I can pass the document from the caller to
ResolveSameStructsAs, and get rid of the pres context pointer.
Differential Revision: https://phabricator.services.mozilla.com/D18600
--HG--
extra : moz-landing-system : lando
This commit is used in a later commit to exclude frames that are sticky positioned
from being scroll anchors.
Differential Revision: https://phabricator.services.mozilla.com/D13266
--HG--
extra : rebase_source : efa0b81269dbf55d14d5702e4e4d4970cce2e5cb
extra : source : 6b96050386f6e9bae6b61747145e204d12cd7cf3
This commit is used in a later commit to exclude frames that are sticky positioned
from being scroll anchors.
Differential Revision: https://phabricator.services.mozilla.com/D13266
--HG--
extra : rebase_source : 50cddce18bbc0164bfff70bf00ab698354ede375
extra : histedit_source : 7cad7389e6958d3107e43e5f915139f6682c168d
It seems that other browsers don't allow 'pointer-events: none' on the root content,
and this can cause us interoperability issues.
Differential Revision: https://phabricator.services.mozilla.com/D12500
--HG--
extra : moz-landing-system : lando
This fixes the regression of three web-platform-test reftests:
testing/web-platform/tests/css/css-contain/contain-paint-002.html
testing/web-platform/tests/css/css-contain/contain-paint-011.html
testing/web-platform/tests/css/css-contain/contain-paint-012.html
that was caused by patch 1, but it's written on top of the code in
patches 2 and 3 so it's easier to fix afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D2812
--HG--
extra : rebase_source : 030c72d1f2945795afe8a81112cd6cb7035d9d6b
This fixes a rather subtle bug. What the underlying code here is trying
to do is remove nsChangeHint_UpdateContainingBlock when some properties
that influence whether a frame is a containing block for absolutely
positioned or fixed positioned elements have changed, but the final
calculation of being a containing block has not changed. However, the
old code was using a function that tested whether the style could
*possibly* lead to a frame being a containing block. Some of the
properties (like the transform properties) that lead to being a
containing block, for example, don't apply to non-replaced inlines.
Some, however, do (such as 'filter'). So if there's a dynamic change
adding or removing a filter, on an inline that also has an *ignored*
transform property (like 'transform' or 'perspective') set, then the
code prior to this patch causes us to remove the UpdateContainingBlock
hint.
This patch fixes things by testing whether being a containing block
could have changed for *any* type of frame, by separately testing the
changes.
The added tests fail without the patch and pass with the patch, viewed
in isolation. However, without the previous patch, test 003 passes.
Test 003 also fails in Chrome (but 001 and 002 pass).
Differential Revision: https://phabricator.services.mozilla.com/D2814
--HG--
extra : rebase_source : 0a5dbb15a058cf4a43d989bf53f042c5b718e24d
This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
--HG--
extra : rebase_source : 459e8efeb171adad089d94272e143e8c244bd279
extra : source : 65ba2f174fcf7dba4e59c00ee8908b1bd0820a48