Instead of passing up stacking containers created by floated content,
keep them in their original parent stacking containers. This is in in
line with specification text for stacking containers:
> To paint a stacking container, given a box root and a canvas canvas:
>
> 1. Paint a stacking context given root and canvas, treating root as
> if it created a new stacking context, but omitting any positioned
> descendants or descendants that actually create a stacking context
> (letting the parent stacking context paint them, instead).
Backport several style changes from Gecko (4)
<!-- Please describe your changes on the following line: -->
This continues https://github.com/servo/servo/pull/29816.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because ___
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Layout 2020: Properly handle negative margins in floats
If a float has negative block margins, it should be pushed upward, but shouldn't affect the positioning of any floats that came before it. It should lower the ceiling though when it still has some non-negative block contribution. In order to implement this behavior, we should only place the float considering its non-negative block length contribution. If the float is pushed up completely past it's "natural" position, it should be placed like a float with zero block size.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] There are tests for these changes
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
If a float has negative block margins, it should be pushed upward, but
shouldn't affect the positioning of any floats that came before it. It
should lower the ceiling though when it still has some non-negative
block contribution. In order to implement this behavior, we should only
place the float considering its non-negative block length contribution. If
the float is pushed up completely past it's "natural" position, it
should be placed like a float with zero block size.
Fix infinite loop in flexbox algorithm
Only apply step 5c of "resolve flexible lengths" if sum of scaled flexible shrink factors > 0
Probably fixes#29852 (but speculative as I can't get mach to run).
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because ___
The flags stylo cares about reading and writing potentially at the same
time are disjoint, so there's no need for any strong memory ordering.
Differential Revision: https://phabricator.services.mozilla.com/D141829
This should be cheap and gives us a lot of memory savings for the page
on the bug, by deduplicating the inherited properties between parent and
children.
WebKit implements a similar optimization.
Differential Revision: https://phabricator.services.mozilla.com/D140826
If a name is not in self.seen, it means we've inherited it from our
parent. That in turn means that it can't have any variable reference
(because we inherit the computed variables) and we can skip the work of
traversing it, as we'd hit the early-return in traverse() anyways.
This doesn't fix the memory usage issue of the page on the bug, which
has a giant list of properties on the root and then a custom property
specified on all elements, but should significantly reduce the time we
spend iterating over custom properties for all those elements.
Differential Revision: https://phabricator.services.mozilla.com/D140825
As mentioned in bug 1747354, the location of the dist directory is
relied to be $topobjdir/dist, so just use that consistently rather
than getting it from a separate variable for rust build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D136556
If the theme is dark but user prefers light pages, the background of the
tabpanel should arguably be light, since it can be seen across some
navigations.
Expose a -moz-content-prefers-color-scheme media query to chrome pages
so that our UI can correctly query it (and remove the unused -moz-proton
atom while at it).
Differential Revision: https://phabricator.services.mozilla.com/D136437
The issue here is that we end up with a transition between mismatched
transform lists that ends up generating an InterpolateMatrix {}
operation. So far so good, but we end up interpolating that a lot of
times and generating an unboundedly-deep operation list.
This implementas an optimization that flattens them to a single matrix
when possible (when there's no dependencies on the containing box).
This is similar to:
https://chromium.googlesource.com/chromium/src.git/+/2b89cc4df436e672ef9cf940d1c0dc73fef82a4a
We fix the to_pixel_length() behavior for LenghtPercentage to be
correct (and update callers to preserve behavior).
Differential Revision: https://phabricator.services.mozilla.com/D134784
Hashbrown grows a lot sometimes making us waste a lot of memory. Shrink
some of these maps after CascadeData rebuild / stylesheet collection
invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D134716
The only remaining consumers are ::-moz-tree pseudo-elements (we used to
use ThinBoxedSlice for other data structures in the past).
Those are not particularly performance sensitive so I think just
double-boxing is fine. In the future, if we wanted to avoid the double
indirection, we could probably use the "thin" crate
(https://docs.rs/thin) or similar, which stores the length of the slice
along with the allocation, making the pointer thin in all
configurations, much like "ThinArc" does:
https://searchfox.org/mozilla-central/rev/1ce2eea39442190a71a1f8f650d098f286bf4a01/servo/components/servo_arc/lib.rs#891
In practice though, I don't think it's particularly worth it for this
specific case.
Differential Revision: https://phabricator.services.mozilla.com/D134672
By modeling it as a separate layer that behaves somewhat specially.
See https://github.com/w3c/csswg-drafts/issues/6872.
The remaining revert-layer tests that we fail are because either we
don't implement a feature (like @property) or because it's used in
keyframes (where revert is a bit unspecified and we have existing
issues with it).
Differential Revision: https://phabricator.services.mozilla.com/D133373
This patch looks bigger than it is, but it's mostly because
of plumbing.
To implement revert-layer we need not only the cascade origin of the
declaration, but the whole cascade level, plus also the layer order.
In order to do this, encapsulate these two things inside a 32-bit
`CascadePriority` struct and plumb it through the rule tree and so on.
This allows us to remove the packing and unpacking of CascadeLevel,
though I kept the ShadowCascadeOrder limit for now in case we need to
reintroduce it.
Fix `!important` behavior of layers while at it (implementing it in
`CascadeLevel::cmp`, spec quote included since it was tricky to find)
since some revert-layer tests were depending on it.
The style attribute test is failing now, but follow-up commit fixes
it, see spec issue.
In terms of the actual keyword implementation, it's sort of
straight-forward: We implement revert and revert-layer in a shared
way, by storing the cascade priority that reverted it.
Differential Revision: https://phabricator.services.mozilla.com/D133372
This is a "simplified" implementation of 'ic', similar to what Safari Preview
currently supports: it only considers the advance of U+6C34 if found in the
first available font, and otherwise falls back to the default of 1em.
(The spec allows for this "in cases where it is impossible or impractical to
determine the ideographic advance measure".)
Differential Revision: https://phabricator.services.mozilla.com/D132818
Based on our previous patches, we only support default behavior for
source and scroll-offsets:
1. source:auto
2. scroll-offsets: none
3. scroll-offsets: auto, auto, ...
So update the parser for them. We expect to remove whole
@scroll-timeline in Bug 1733260, so now only do a tiny update in parser.
Differential Revision: https://phabricator.services.mozilla.com/D132417
