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
This matches the spec, https://drafts.csswg.org/css-values/#angles, which says:
> All <angle> units are compatible, and deg is their canonical unit.
And https://drafts.csswg.org/css-values/#compat, which says:
>When serializing computed values [...], compatible units [...] are converted into a single canonical unit.
And also other implementations (Blink always serializes angles as degrees in
computed style for example).
Also allows us to get rid of quite a bit of code, and makes computed angle value
representation just a number, which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D8619
There are a few mentions of nsRuleNode left but they are mostly
historical references so it makes sense to keep them.
Differential Revision: https://phabricator.services.mozilla.com/D5505
Prior to this change, if none of the fonts specified in CSS contained a
glyph for a codepoint, we tried only one fallback font. If that font
didn't contain the glyph, we'd give up.
With this change, we try multiple fonts in turn. The font names we try
differ across each platform, and based on the codepoint we're trying to
match. The current implementation is heavily inspired by the analogous
code in Gecko, but I've used to ucd lib to make it more readable,
whereas Gecko matches raw unicode ranges.
This fixes some of the issues reported in #17267, although colour emoji
support is not implemented.
== Notes on changes to WPT metadata ==
=== css/css-text/i18n/css3-text-line-break-opclns-* ===
A bunch of these have started failing on macos when they previously
passed.
These tests check that the browser automatically inserts line breaks
near certain characters that are classified as "opening and closing
punctuation". The idea is that if we have e.g. an opening parenthesis,
it does not make sense for it to appear at the end of a line box; it
should "stick" to the next character and go into the next line box.
Before this change, a lot of these codepoints rendered as a missing
glyph on Mac and Linux. In some cases, that meant that the test was
passing.
After this change, a bunch of these codepoints are now rendering glyphs
on Mac (but not Linux). In some cases, the test should continue to pass
where it previously did when rendering with the missing glyph.
However, it seems this has also exposed a layout bug. The "ref" div in
these tests contains a <br> element, and it seems that this, combined
with these punctuation characters, makes the spacing between glyphs ever
so slightly different to the "test" div. (Speculation: might be
something to do with shaping?)
Therefore I've had to mark a bunch of these tests failing on mac.
=== css/css-text/i18n/css3-text-line-break-baspglwj-* ===
Some of these previously passed on Mac due to a missing glyph. Now that
we're rendering the correct glyph, they are failing.
=== css/css-text/word-break/word-break-normal-bo-000.html ===
The characters now render correctly on Mac, and the test is passing. But
we do not find a suitable fallback font on Linux, so it is still failing
on that platform.
=== css/css-text/word-break/word-break-break-all-007.html ===
This was previously passing on Mac, but only because missing character
glyphs were rendered. Now that a fallback font is able to be found, it
(correctly) fails.
=== mozilla/tests/css/font_fallback_* ===
These are new tests added in this commit. 01 and 02 are marked failing
on Linux because the builders don't have the appropriate fonts installed
(that will be a follow-up).
Fix build errors from rebase
FontTemplateDescriptor can no longer just derive(Hash). We need to
implement it on each component part, because the components now
generally wrap floats, which do not impl Hash because of NaN. However in
this case we know that we won't have a NaN, so it is safe to manually
impl Hash.
This also changes their ToCss impl to use SequenceWriter instead of
checking has_value manually.
SpecifiedValueInfo for those types are also implemented in this patch.
Bug: 1434130
Reviewed-by: emilio
MozReview-Commit-ID: 23h2VWS417H
