This improves the behavior significantly. Transitions that are not
running on the compositor but are throttled on the main thread due to
being scrolled out of view have the same issue as compositor animations.
Differential Revision: https://phabricator.services.mozilla.com/D229026
Make it an alias of the preserve-spaces value, and don't bother
serializing the shorthand to that value.
Update internal usages to the standard keyword.
Differential Revision: https://phabricator.services.mozilla.com/D228958
We want to conditionally parse `anchor()`, but:
1. It's not really a unit.
2. When interleaving gets implemented, we'd treat it just line `<length-percentage>`,
but still need the conditional parsing.
Differential Revision: https://phabricator.services.mozilla.com/D228551
32-bit build does this, and causes a circular dependency when `anchor()` is
added. Since its fallback is `<length-percentage>`, there'd be a circular
dependency.
Differential Revision: https://phabricator.services.mozilla.com/D227499
Bug 1926969 introduces a new example of computational dependence:
Color-scheme dependent colors like `light-dark()` and system colors. So
specific references to lengths, like `allows_font_relative_lengths`,
should be generalized.
This patch also renames `ParsingMode::DISALLOW_FONT_RELATIVE` to
`ParsingMode::DISALLOW_COMPUTATIONALLY_DEPENDENT`.
ParserContext::allows_computational_dependence is added for convenience.
Differential Revision: https://phabricator.services.mozilla.com/D226868
to_shmem and to_shmem_derive need a description, and selectors needs a
version bump.
Tweak supply-chain audits / config to deal with now published crates.
Differential Revision: https://phabricator.services.mozilla.com/D226468
When I rewrote this code in bug 1874050, the assumption was that doing
the right thing was fine because we were more likely to take the fast
path for the owned properties (the parent_ptr_eq()).
But given this shows up in profiles, let's do the order-aware comparison
(which might return false in some cases where it doesn't need to, but
seems to be a better trade-off with tons of custom properties).
Differential Revision: https://phabricator.services.mozilla.com/D226612
Product nodes are eagerly resolved during parse time, but sum nodes are
not. This might cause floating point inprecision in sum nodes, which
leads to invalid calculations, e.g. `round(down, (7 - 1) / 3, 1)` would
end up being `round(down, (2.3333333 - 0.33333334), 1)`, then
`round(down, 1.99999996, 1)`, which equals `1`, which is incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D225936
We now fully support the full ColorFunction in the ComputedStyle struct
in layout. This solves an issue where colors are copied on the C++
side.
Some structs had to be renamed to avoid name collisions in the generates
C++ code.
Some specified structs has the #[repr(C)] attribute now to include them
in the ComputedStyle struct. This is not really correct as they are
specified values and only computed values should be there. Splitting all
the unit structs into specified and computed is a lot of changes so
there is a follow up bug here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1924483
Differential Revision: https://phabricator.services.mozilla.com/D225080
When an alpha component is omitted, instead of defaulting to opaque,
colors with an origin color used the alpha from there.
Differential Revision: https://phabricator.services.mozilla.com/D223134
When we have a color that can't be resolved at parse time (or should not
be resolved) then we store the data that was parsed as is to preserve
all the data for round tripping.
Differential Revision: https://phabricator.services.mozilla.com/D220268
Color components can now preserve parsed data, including calc nodes, if
required.
Some of the computed color tests fail, because we don't have the origin
color readily available to determine which color format to use. (e.g.
color instead of rgb). Fixes are in a follow up patch: D220268
Differential Revision: https://phabricator.services.mozilla.com/D220124
The zoom factor is stored as a fixed point number, and the effective zoom may
be close to 0 (because we have to mulitply the zoom values of ancestors).
So we have to make sure we don't divide by zero because the effective zoom
could be zero.
Differential Revision: https://phabricator.services.mozilla.com/D224551
I think this is a bit more consistent, and makes us preserve the
invariant that from_computed_value().to_computed_value() round-trips.
Differential Revision: https://phabricator.services.mozilla.com/D223878
