This is a backport of https://phabricator.services.mozilla.com/D143942,
by Emilio Cobos Álvarez.
This doesn't change behavior on its own, but the current code introduces
some minor floating point error which we can avoid, and which would
cause failures with the patch for #29696.
This renames the internal -moz-math-script-level property in order to
prepare for full math-depth support. Currently, the property is guarded
under a disabled-by-default flag, so there should be no observable
behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D91285
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
We have this optimization where, for non-generic structs, we generate just a
clone / move as the ToComputedValue / ToResolvedValue implementation.
This moves the optimization a bit further down, and refines it so that we still
generate all the relevant where clauses that make it sound, that is, that all
the ToComputedValue implementations of the fields return the same type.
Otherwise this wouldn't be sound and the type would need to become generic.
We add an escape hatch (no_field_bound) for fields that need to be cloned but
which don't implement the trait. This is right now only for the RefPtr<> in the
shared font-family list, and a piece of code in PaintWorklet which looks kinda
fishy, and probably should be fixed (but we don't ship it in Firefox and there's
a pre-existing FIXME for servo, so I punted on it for now).
The other thing this patch does is adding a bunch of ToComputedValue /
ToResolvedValue implementations that are trivial and were missing.
Differential Revision: https://phabricator.services.mozilla.com/D67913
This simplifies a bit the code, and guarantees that all calc()s have percentages
and lengths.
I also wanted to remove unclamped_length() / specified_percentage() (for the
same reason as the above patch), but they're needed for animations for now. When
I implement min() / max() for <length-percentage> they'll be fixed.
Differential Revision: https://phabricator.services.mozilla.com/D60194
It does not make any sense with min() / max() / clamp. So just forget the
keyword info when calc() is used. This also removes a bit of complex / hacky
code.
Differential Revision: https://phabricator.services.mozilla.com/D60663
Font code is the only thing that was using Au in the style system without
interfacing with Gecko, and there was no real reason for it to do so.
This slightly simplifies the code.
Differential Revision: https://phabricator.services.mozilla.com/D57248
These two bugs (bug 1572738 and bug 1572451) are stylo regressions.
When font-family changes, we try to recompute the font-size with a length /
percentage combinations in case the generic family changes, so the user
preferences are kept.
When calc() is involved, we clamp to non-negative too early, via
NonNegativeLength::scale_by.
I think we should generally dump this "try to track font-size across calc()"
thingie, as as various comments note it is not quite perfect, and it's not clear
how it should work in presence of min()/max().
This patch fixes the issue and simplifies code a bit, I may consider removing
this altogether in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D41776
To be more similar between Rust and C++. This introduces GenericFontFamily and
exposes that plus FontFamilyNameSyntax to C++, using that where appropriate
instead of plain uint8_t as we were doing.
As a follow-up, as discussed on IRC with Jonathan, we can remove the -moz-fixed
family, and turn it just into an alias of Monospace.
The only non-trivial change is the MatchType changes, but they're ok I think.
The code already assumed at most one CSS generic, and the struct still takes 8
bits. I've verified that the relevant tests are passing (though try is closed).
Differential Revision: https://phabricator.services.mozilla.com/D24272
UA style sheets only ever specify a single generic font family in font-family
properties, so we pre-create a unique, static SharedFontList for each generic
and change the representation of FontFamilyList to be able to refer to them
by their generic ID. This avoids having to share refcounted SharedFontList
objects across processes.
Differential Revision: https://phabricator.services.mozilla.com/D17183
It's not very easy to understand on its current state, and it causes subtle bugs
like bug 1533654.
It could be simpler if we centralized where the interactions between properties
are handled. This patch does this.
This patch also changes how MathML script sizes are tracked when scriptlevel
changes and they have relative fonts in between.
With this patch, any explicitly specified font-size is treated the same (being a
scriptlevel boundary), regardless of whether it's either an absolute size, a
relative size, or a wide keyword.
Relative lengths always resolve relative to the constrained size, which allows
us to avoid the double font-size computation, and not give up on sanity with
keyword font-sizes.
I think given no other browser supports scriptlevel it seems like the right
trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D23070
I want to do this so that I can get rid of Either<>. The reasons for getting rid
of either are multiple:
* It doesn't generate as nice C++ code using cbindgen.
* It isn't that nice to use either from Rust.
* cbindgen has bugs with zero-sized types.
I started using this for ColorOrAuto and a few others, for now.
Differential Revision: https://phabricator.services.mozilla.com/D19844
It does not represent `<length> | <percentage>`, but `<length-percentage>`, so
`LengthOrPercentage` is not the right name.
This patch is totally autogenerated using:
rg 'LengthOrPercentage' servo | cut -d : -f 1 | sort | uniq > files
for file in $(cat files); do sed -i "s#LengthOrPercentage#LengthPercentage#g" $file; done
Differential Revision: https://phabricator.services.mozilla.com/D15812
This is a first step to share LengthOrPercentage representation between Rust and
Gecko.
We need to preserve whether the value came from a calc() expression, for now at
least, since we do different things depending on whether we're calc or not right
now. See https://github.com/w3c/csswg-drafts/issues/3482 and dependent bugs for
example.
That means that the gecko conversion code needs to handle calc() in a bit of an
awkward way until I change it to not be needed (patches for that incoming in the
next few weeks I hope).
I need to add a hack to exclude other things from the PartialEq implementation
because the new conversion code is less lossy than the old one, and we relied on
the lousiness in AnimationValue comparison (in order to start transitions and
such, in [1] for example).
I expect to remove that manual PartialEq implementation as soon as I'm done with
the conversion.
The less lossy conversion does fix a few serialization bugs for animation values
though, like not loosing 0% values in calc() when interpolating lengths and
percentages, see the two modified tests:
* property-types.js
* test_animation_properties.html
Differential Revision: https://phabricator.services.mozilla.com/D15793
