These were written at a time where std::mem::size_of wasn't a `const fn` in
Rust.
Now that it is, we can make these tests live in the style crate, and the build
not to compile if they fail.
Differential Revision: https://phabricator.services.mozilla.com/D146103
Much like we track layer rules. Consolidate that "containing rule state
we pass down while building the cascade data" in a single struct that we
can easily restore.
For now, do nothing with it. I want to land this patch separately
because it touches the Rule struct and CascadeData rebuilds, which both
are performance sensitive.
Its layout shouldn't change because I also changed LayerId to be a u16
(this shouldn't matter in practice, since LayerOrder is already a u16).
Differential Revision: https://phabricator.services.mozilla.com/D145243
In my investigation for bug 1766439, I am digging into why selector
matching regressed.
It doesn't help that the selector-matching code is instantiated a
gazillion times (so there's a ton of copies of the relevant functions).
This was needed in the past because we had different ways of setting the
selector flags on elements, but I unified that recently and now we only
need to either set them or not. That is the kind of thing that
MatchingContext is really good for, so pass that instead on
MatchingContext creation.
Differential Revision: https://phabricator.services.mozilla.com/D145428
There's nobody working on it, and tooltips should hopefully be nice
enough after recent changes (bug 1765423).
Having it enabled causes artifacts like bug 1767815 comment 3. We can
always rescue this from hg history if needed.
Differential Revision: https://phabricator.services.mozilla.com/D145621
cross-fade() was kinda doing this in its own way with PercentOrNone, but
since now we have more use-cases for this we should probably make this a
slightly more general solution.
I added some convenience APIs, but they're unused as of this patch so
let me know if you want them gone.
Differential Revision: https://phabricator.services.mozilla.com/D144831
There are some mediaqueries-5 features that we still don't support and
explain the remaining failures in at-container-{parsing,serialization}.
Differential Revision: https://phabricator.services.mozilla.com/D144446
Make the representation the same between Gecko and Servo code. This will
enable further clean-ups in the future.
Make serialization be correct, serializing as identifier unless it's an
invalid one (in which case we serialize as a string).
This changes our stringification behavior in the specified style, but
now it will match the computed style and be more correct over-all.
Differential Revision: https://phabricator.services.mozilla.com/D144473
No behavior change, just moving and renaming files.
The code in the "queries" module will be shared between @media and
@container.
@media has some other code that container queries doesn't need like
MediaList / MediaType / etc. That remains in the media_queries module.
Differential Revision: https://phabricator.services.mozilla.com/D144435
This has no behavior change otherwise. The STRICT definition depended on
SIZE, which was defined later. That's fine in Rust, but in C++ it causes
the initialization to be dynamic because it doesn't have the definition
of SIZE yet (ugh).
This is the fix for the regression, though the following patch turns on
constexpr support in cbindgen, which would've caught this at build-time,
and guarantees that we don't have extra static constructors.
Differential Revision: https://phabricator.services.mozilla.com/D144316
This has no behavior change right now, but will simplify sharing code
with container queries.
Container queries will have container information in the
computed::Context (this is necessary anyways for container-based units),
so this avoids having to have different code for media and container
queries.
Differential Revision: https://phabricator.services.mozilla.com/D144152
This mostly just moves code around, to minimize potential behavior
changes. There are some cleanups that we should try to do long term
(this "have an array with n different counts" is pretty weird).
But for now this should unblock people.
The destination struct (nsStyleUIReset) was chosen mainly because it's
small and non-inherited, and it doesn't seem like a worse place than
nsStyleDisplay.
Differential Revision: https://phabricator.services.mozilla.com/D144183
This patch:
* Removes generic <ident> support for media features. These were used
for some privileged media features but are no longer used.
* Simplifies media feature getters by shifting the responsibility of
dealing with RangeOrOperator to the caller. This makes it easier to
implement container-query / mediaqueries-4 syntax, and also cleans up
the code a bunch.
There should be no change in behavior.
Differential Revision: https://phabricator.services.mozilla.com/D144051
Before bug 1763750, we unconditionally called compute_writing_mode,
which got the writing mode from the cascade mode for visited styles.
However after that bug we only do that if we apply any
writing-mode-related property.
We could just call compute_writing_mode unconditionally, but instead it
seems better to skip all that work for visited cascade and reuse the
mechanism introduced in that bug to only apply the visited-dependent
longhands.
We assert that all visited-dependent longhands are "late" longhands, so
as to also avoid applying the font group and such.
Differential Revision: https://phabricator.services.mozilla.com/D143490
I was unable to change the BLOOM_KEY field to no longer be leaked, as the TLS
is also accessed on the main thread, which is not exited before the leak
checker shuts down.
Differential Revision: https://phabricator.services.mozilla.com/D143529
This makes the worst case for cascade performance slightly more
expensive (4 rather than three declaration walks), but my hope is that
it will make the average case faster, since the best case is now just
two walks instead of three, and writing mode properties are somewhat
rare.
This needs a test, but needs to wait until the writing-mode dependent
viewport units land (will wait to land with a test).
Differential Revision: https://phabricator.services.mozilla.com/D143261
This allows popups and sidebars to use the chrome preferred
color-scheme.
This moves the responsibility of setting the content-preferred color
scheme to the appropriate browsers to the front-end (via tabs.css).
We still return the PreferredColorSchemeForContent() when there's no
pres context (e.g., for display:none in-process iframes). We could
potentially move a bunch of the pres-context data to the document
instead, but that should be acceptable IMO as for general web content
there's no behavior change in any case.
Differential Revision: https://phabricator.services.mozilla.com/D142578
Remember whether we have already de-duplicated them once and avoid doing
that again.
This is an alternative approach that doesn't add overhead to attribute
setting in the general case.
Differential Revision: https://phabricator.services.mozilla.com/D142813
Two noteworthy details that may seem random otherwise:
* Moving values around in nsStyleDisplay is needed so that the struct
remains under the size limit that we have to avoid jumping allocator
buckets.
* All the test expectation churn is because tests depend on
`container-type: size` parsing to run, and now they run. Tests for
the relevant bits I implemented are passing, with the only exception
of some `container-name-computed.html` failures which are
https://github.com/w3c/csswg-drafts/issues/7181. Safari agrees with
us there.
Other notes when looking at the spec and seeing how it matches the
implementation:
* `container` syntax doesn't match spec, but matches tests and sanity:
https://github.com/w3c/csswg-drafts/issues/7180
* `container-type` syntax doesn't _quite_ match spec, but matches tests
and I think it's a spec bug since the definition for the missing
keyword is gone:
https://github.com/w3c/csswg-drafts/issues/7179
Differential Revision: https://phabricator.services.mozilla.com/D142419
We keep getting this pattern of properties that have a set of joint and
disjoint flags, and copy-pasting or writing the same parsing and
serialization code in slightly different ways.
container-type is one such type, and I think we should have a single way
of dealing with this, thus implement deriving for various traits for
bitflags, with an attribute that says which flags are single vs mixed.
See docs and properties I ported. The remaining ones I left TODOs with,
they are a bit trickier but can be ported with some care.
Differential Revision: https://phabricator.services.mozilla.com/D142418
