We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
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 feel a bit weird for using LenghtPercentageOrAuto to implement LengthOrAuto,
but I don't think much other code will use it so it seemed a bit better to me.
Differential Revision: https://phabricator.services.mozilla.com/D21863
This also adopts the resolution from [1] while at it, making letter-spacing
compute to a length, serializing 0 to normal rather than keeping normal in the
computed value, which matches every other engine.
This removes the SMIL tests for percentages from letter-spacing since
letter-spacing does in fact not support percentages, so they were passing just
by chance.
[1]: https://github.com/w3c/csswg-drafts/issues/1484
Differential Revision: https://phabricator.services.mozilla.com/D21850
As it turns out we need this to avoid losing precision both during painting and
during serialization.
This patch also changes to serialize `context-value` if it's the computed value.
I could keep the previous behavior, but it makes no sense to serialize the
initial value. We're the only ones to support this value anyway, and I couldn't
find a definition or spec for this.
Also update tests and expectations for:
* New unexpected passes.
* Always serializing the unit in getComputedStyle.
* Calc and interpolation support.
Chrome also always serializes the unit in getComputedStyle, so I'm pretty sure
this is compatible with them. Chrome is inconsistent and keeps numbers in
specified style, but that's inconsistent with itself and with other quirky
lengths, so I updated the tests instead.
Differential Revision: https://phabricator.services.mozilla.com/D21819
Otherwise the Trait for clamping negative animation value isn't generated thus
negative animating results are exposed in computed values.
Differential Revision: https://phabricator.services.mozilla.com/D21153
Converted the #define variable NS_STYLE_FLEX_DIRECTION to an enum class in nsStyleConsts.h and made changes in other files that access it
Differential Revision: https://phabricator.services.mozilla.com/D20291
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
-moz-tab-size, border-image-outset and border-image-slice.
This is not a particularly interesting patch, just removes some code. We can
remove way more code when a few related properties are also ported.
Differential Revision: https://phabricator.services.mozilla.com/D19825
The reason why we use RelaxedAtomBool is that
ScrollSnapUtils::GetSnapPointForDestination() is called both from the main and
the compositor threads, and the function will have a branch depending on the
pref value.
Differential Revision: https://phabricator.services.mozilla.com/D20101
Really sorry for the size of the patch :(
Only intentional behavior change is in the uses of HasLengthAndPercentage(),
where it's easier to do the right thing. The checks that used to check for
(IsCalcUnit() && CalcHasPercentage()) are wrong since bug 957915.
Differential Revision: https://phabricator.services.mozilla.com/D19553
This patch:
* Makes LengthPercentageOrAuto generic, and removes a bunch of code fo
LengthPercentageOrNone, which was used only for servo and now can use the
normal MaxLength (with a cfg() guard for the ExtremumLength variant).
* Shrinks MaxLength / MozLength's repr(C) reperesentation by reducing enum
nesting. The shrinking is in preparation for using them from C++ too, though
that'd be a different bug.
* Moves NonNegative usage to the proper places so that stuff for them can be
derived.
I did this on top of bug 1523071 to prove both that it could be possible and
that stuff wasn't too messy. It got a bit messy, but just because of a bug I
had fixed in bindgen long time ago already, so this updates bindgen's patch
version to grab a fix instead of ugly workarounds :)
Differential Revision: https://phabricator.services.mozilla.com/D17762
But enable it in all tests because a lot of them rely on using it in the
style="" attribute for example, or in inline stylesheets, which will no longer
parse this (even in chrome documents), and we don't want to rewrite all the XUL
and XBL tests.
Differential Revision: https://phabricator.services.mozilla.com/D18027
Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1348519#c6 and
https://github.com/w3c/csswg-drafts/issues/3201:
Currently grid-template-rows/columns interpolate “per computed value”, which
means that if the number of tracks differs, or any track changes to/from a
particular keyword value to any other value, or if a line name is added/removed
at any position, the entire track listing is interpolated as “discrete”.
But we "agree" with two more granular options:
1. Check interpolation type per track, rather than for the entire list, before
falling back to discrete. I.e. a length-percentage track can animate between
two values while an adjacent auto track flips discretely to min-content.
2. Allow discrete interpolation of line name changes independently of track
sizes.
Besides, for the repeat() function, it's complicated to support interpolation
between different repeat types (i.e. auto-fill, auto-fit) and different repeat
counts, so we always fall-back to discrete if the first parameter of repeat()
is different.
Differential Revision: https://phabricator.services.mozilla.com/D16129
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
