Which is more appropriate, given it represents a `<media-feature>` per spec, and
expression is a bit overloaded :)
Bug: 1422225
Reviewed-by: xidorn
MozReview-Commit-ID: Fed1nJhHxDu
The only bit from the spec which I haven't implemented to my knowledge is the
bit that allows you to swap the position of the media feature and the value,
because it unnecessarily complicates parsing (we parse the value in terms of the
feature), and I don't think it's useful given how easy it is to switch from,
e.g., `(500px > width)` to `(width <= 500px)`.
I filed https://github.com/w3c/csswg-drafts/issues/2791 about it.
Bug: 1422225
Reviewed-by: xidorn
MozReview-Commit-ID: 6xrdVl87S9X
This reduces memory usage because we only need one allocation instead of two
for the dynamic atom and its chars, and because we don't need to store a
refcount and a size. It precludes sharing of chars between dynamic atoms, but
we weren't benefiting much from that anyway.
This reduces per-process memory usage by up to several hundred KiB on my
Linux64 box.
One consequence of this change is that we need to allocate + copy in
DOMString::SetKnownLiveAtom(), which could make some things slower.
Bug: 1447951
Reviewed-by: froydnj
Summary:
This should make it easier to report errors, and also reduce codesize.
The reason this was so generic is that error reporting was unconditionally
enabled and was super-hot, but now that's no longer the case after bug 1452143,
so we can afford the virtual call in the "error reporting enabled" case.
This opens the possibility of simplifying a lot the error setup as well, though
this patch doesn't do it.
Test Plan: No behavior change, so no new tests.
Reviewers: xidorn
Bug #: 1469957
Differential Revision: https://phabricator.services.mozilla.com/D1734
MozReview-Commit-ID: F3wTdhX9MB5
We were spuriously reframing the <shadow> because it initially shared style with
the <br>, which ended up being display: none, while the <shadow> should've been
display: contents from the beginning.
lookup_by_rules seems pretty prone to obscure bugs, and also it's pretty
complex... Probably we should try to get rid of it, I'm unconvinced that it's
worth it.
Even with that, in a normal restyle the <details> wouldn't have ended up with a
style. It of course never had it before the reframe because the <shadow> was
display: none, but that doesn't mean it shouldn't have gotten one, since we
detected we needed to go through kids in:
https://searchfox.org/mozilla-central/rev/6eea08365e7386a2b81c044e7cc8a3daa51d8754/servo/components/style/matching.rs#500
That code did happen, but since it's an animation-only restyle, we don't look at
unstyled stuff.
That looks somewhat fishy, but I guess for now it's fine as long as display
isn't animatable.
Bug: 1469076
Reviewed-by: heycam
MozReview-Commit-ID: B6NMSTNOKgK
We may end up looking at a non-flushed AuthorStyles object when looking at
whether attribute changes and such may affect style.
Check the styles are clean to preserve the assertion, since if that happens
before the first flush, we may not have updated the quirks_mode field (and
that's fine).
Bug: 1468640
MozReview-Commit-ID: FgVpiTf4qMr
It's possible that both this_weight and other_weght have calculation errors
which are approximately equal to f64::EPSILON.
Bug: 1468294
Reviewed-by: birtles
MozReview-Commit-ID: 8OddG9rI3qd
Media feature names are converted to lower case before being processed, making
them effectively case-insensitive.
Prefixes ("min-", etc.) and values are already treated in a case-insensitive
manner.
Bug: 1464091
Reviewed-by: heycam
MozReview-Commit-ID: JUeeEQEMIi4
The idea is to turn the simple properties into a blacklist instead really soon,
and fix the offending ones soon after, so that only shorthands and properties
with layout dependence (and maybe the scrollbar properties, because the poke at
LookAndFeel) are not serialized by Servo.
Bug: 1467536
Reviewed-by: xidorn
MozReview-Commit-ID: JTLNnmXzny8
Extract the common parts of `animated::Color` and `computed::Color` out
into `generics::color::Color<T>` that is generic over the type of
RGBA color.
Bug: 1465307
Reviewed-by: xidorn
MozReview-Commit-ID: EymSr7aqnAP
GCC doesn't like StyleComplexColor with constructor in an anonymous
struct in an anonymous union. Replace the use of a union to access
`mBorder[..]Color` fields as an array with an accessor methods.
Bug: 1465307
Reviewed-by: xidorn
MozReview-Commit-ID: 1Wulh1qKYCZ
Refactored StyleComplexColor to support "complex" blending between
background (numeric) color and foreground color (currentColor).
Made explicit the distinction between numeric, currentColor and a
complex blend in Gecko and Stylo.
This is to support SMIL animation, for example, of the form:
<animate from="rgb(10,20,30)" by="currentColor" ... />
Bug: 1465307
Reviewed-by: hiro,xidorn
MozReview-Commit-ID: IUAK8P07gtm
Atomic<bool> is implemented in terms of AtomicBase<uint32_t>, because that way
you don't need to depend on atomic 1-byte operations. That means that the rust
bindgen sees it as a u32, not a bool.
It's a bit concerning that the rust code seems to be doing an unsynchronized
read here, but given this is a RelaxedAtomic, that's probably ok.
Bug: 1467134
Reviewed-by: emilio
It's only used for the error path in property parsing, so most of the time is
not useful.
Use the just-introduced NonCustomPropertyId::name to preserve the alias name,
which we were doing by passing the name around.
Bug: 1466645
Reviewed-by: xidorn
MozReview-Commit-ID: 46xxZKCoeBB
