Bug 1746084 - Avoid generating InterpolateMatrix operations if there are no size dependencies. r=hiro

The issue here is that we end up with a transition between mismatched
transform lists that ends up generating an InterpolateMatrix {}
operation. So far so good, but we end up interpolating that a lot of
times and generating an unboundedly-deep operation list.

This implementas an optimization that flattens them to a single matrix
when possible (when there's no dependencies on the containing box).

This is similar to:

  https://chromium.googlesource.com/chromium/src.git/+/2b89cc4df436e672ef9cf940d1c0dc73fef82a4a

We fix the to_pixel_length() behavior for LenghtPercentage to be
correct (and update callers to preserve behavior).

Differential Revision: https://phabricator.services.mozilla.com/D134784

It's been enabled by default since ~forever.

Differential Revision: https://phabricator.services.mozilla.com/D134935

MANUAL PUSH: Trivial rename.

Differential Revision: https://phabricator.services.mozilla.com/D134802

Differential Revision: https://phabricator.services.mozilla.com/D134779

Hashbrown grows a lot sometimes making us waste a lot of memory. Shrink
some of these maps after CascadeData rebuild / stylesheet collection
invalidation.

Differential Revision: https://phabricator.services.mozilla.com/D134716

The only remaining consumers are ::-moz-tree pseudo-elements (we used to
use ThinBoxedSlice for other data structures in the past).

Those are not particularly performance sensitive so I think just
double-boxing is fine. In the future, if we wanted to avoid the double
indirection, we could probably use the "thin" crate
(https://docs.rs/thin) or similar, which stores the length of the slice
along with the allocation, making the pointer thin in all
configurations, much like "ThinArc" does:

  https://searchfox.org/mozilla-central/rev/1ce2eea39442190a71a1f8f650d098f286bf4a01/servo/components/servo_arc/lib.rs#891

In practice though, I don't think it's particularly worth it for this
specific case.

Differential Revision: https://phabricator.services.mozilla.com/D134672

It does the same, but it saves an indentation level:

  https://searchfox.org/mozilla-central/rev/a11b63915bd7810a03635d733123448ab5bfcad3/third_party/rust/rayon-core/src/thread_pool/mod.rs#217

Differential Revision: https://phabricator.services.mozilla.com/D134321

Partially backs out the previous patch.

Differential Revision: https://phabricator.services.mozilla.com/D134256

The changes to the devtools directory were written automatically via ./mach devtools-css-db

Differential Revision: https://phabricator.services.mozilla.com/D134197

Differential Revision: https://phabricator.services.mozilla.com/D134194

Backed out changeset e9782fd301cc (bug 1746683) for causing mochitest failures in layout/inspector/tests/test_bug877690.html CLOSED TREE

The changes to the devtools directory were written automatically via ./mach devtools-css-db

Differential Revision: https://phabricator.services.mozilla.com/D134197

Differential Revision: https://phabricator.services.mozilla.com/D134010

Differential Revision: https://phabricator.services.mozilla.com/D133889

Backed out changeset fa4f889dd0d3 (bug 1746187)
Backed out changeset e3fce2273109 (bug 1746187)
Backed out changeset 6733677ad35d (bug 1746187)
Backed out changeset a4375ff93414 (bug 1746187)

Differential Revision: https://phabricator.services.mozilla.com/D133889

This is a better fix for the double decorations than clipping them using
CSS.

Differential Revision: https://phabricator.services.mozilla.com/D133871

Bug 1745233 - Update CSSOM for layer rules to the spec. r=firefox-style-system-reviewers,layout-reviewers,boris

Pretty mechanical.

Tests are in https://wpt.live/css/css-cascade/layer-rules-cssom.html
which (with a fix for @import tests which I'll submit separately) we
pass.

Sync for that is bug 1743936.

Differential Revision: https://phabricator.services.mozilla.com/D133387

Bug 1699220 - Fix style attribute important and revert-layer behavior. r=firefox-style-system-reviewers,layout-reviewers,boris

By modeling it as a separate layer that behaves somewhat specially.

See https://github.com/w3c/csswg-drafts/issues/6872.

The remaining revert-layer tests that we fail are because either we
don't implement a feature (like @property) or because it's used in
keyframes (where revert is a bit unspecified and we have existing
issues with it).

Differential Revision: https://phabricator.services.mozilla.com/D133373

This patch looks bigger than it is, but it's mostly because
of plumbing.

To implement revert-layer we need not only the cascade origin of the
declaration, but the whole cascade level, plus also the layer order.

In order to do this, encapsulate these two things inside a 32-bit
`CascadePriority` struct and plumb it through the rule tree and so on.
This allows us to remove the packing and unpacking of CascadeLevel,
though I kept the ShadowCascadeOrder limit for now in case we need to
reintroduce it.

Fix `!important` behavior of layers while at it (implementing it in
`CascadeLevel::cmp`, spec quote included since it was tricky to find)
since some revert-layer tests were depending on it.

The style attribute test is failing now, but follow-up commit fixes
it, see spec issue.

In terms of the actual keyword implementation, it's sort of
straight-forward: We implement revert and revert-layer in a shared
way, by storing the cascade priority that reverted it.

Differential Revision: https://phabricator.services.mozilla.com/D133372

This is a better fix for the double decorations than clipping them using
CSS.

Differential Revision: https://phabricator.services.mozilla.com/D133871

This is a "simplified" implementation of 'ic', similar to what Safari Preview
currently supports: it only considers the advance of U+6C34 if found in the
first available font, and otherwise falls back to the default of 1em.

(The spec allows for this "in cases where it is impossible or impractical to
determine the ideographic advance measure".)

Differential Revision: https://phabricator.services.mozilla.com/D132818

Differential Revision: https://phabricator.services.mozilla.com/D133101

Based on our previous patches, we only support default behavior for
source and scroll-offsets:
1. source:auto
2. scroll-offsets: none
3. scroll-offsets: auto, auto, ...

So update the parser for them. We expect to remove whole
@scroll-timeline in Bug 1733260, so now only do a tiny update in parser.

Differential Revision: https://phabricator.services.mozilla.com/D132417

Bug 1676791 - Part 8: Hook scroll-timeline rule into Cascade data and use it for CSS animations. r=emilio,hiro

We hook the rule into cascade data, and so we can look it up by timeline
name. Now we only use StyleScrollDirection from @scroll-timeline rule.
`source` and `scroll-offsets` are skipped now and use the default values
instead because I'm pretty sure the syntax will be changed in Bug 1733260,
and `scroll-offsets` may be obsolete because the spec proposal intents to
make it be always 0% ~ 100%.

Also, add some reftests for the default `source` and `scroll-offsets`,
and different `orientation`s.

Besides, we disable at-scroll-timeline-start-end.html in Gecko because
we don't support start/end descriptors, and there are too many
intermittents in it.

Differential Revision: https://phabricator.services.mozilla.com/D126452

Define a simple version of ScrollTimeline.

Differential Revision: https://phabricator.services.mozilla.com/D129099

Differential Revision: https://phabricator.services.mozilla.com/D131531

Backed out changeset 66eb52e5da74 (bug 1741973) for causing mochitest failures in test_animation-type-longhand.html

CLOSED TREE

Differential Revision: https://phabricator.services.mozilla.com/D131531

Backed out changeset 145c64b7ac17 (bug 1531223) for causing failures at gfxFontEntry.cpp. CLOSED TREE

Differential Revision: https://phabricator.services.mozilla.com/D132818

Backed out changeset 8fac157c354a (bug 1741973) for causing xpc failures in devtools/shared/tests/xpcshell/test_css-properties-db. CLOSED TREE

Differential Revision: https://phabricator.services.mozilla.com/D131531

Bug 1509931 - Use titlebar radius on Linux and make titlebar set-up work for lightweight themes. r=stransky,dao

To do this, we always draw the native titlebar behind the toolbox, and
then make the toolbox adapt to it by using the titlebar radius. This
makes us preserve the shadow properly.

On Wayland we'd double-draw the shadow (see bug 1509931 comment 4) so
this fixes it by trimming it as well using border-radius.

Differential Revision: https://phabricator.services.mozilla.com/D128681

This always draws transparent. Only real thing it does is forcing 0px
padding.

Differential Revision: https://phabricator.services.mozilla.com/D132563

This is based off work by smurfd. But this patch doesn't support buttons
both at the left and right, which simplifies a lot the implementation.

Also, clean-up the existing env variables while at it.

Co-authored-by: Nicklas Boman <smurfd@gmail.com>

Differential Revision: https://phabricator.services.mozilla.com/D132073

It's controlled by the pref:
layout.forms.input-type-show-password-button.enabled

Differential Revision: https://phabricator.services.mozilla.com/D130407

This was a subtle behavior change in bug 1739464. The early-return here:

  https://hg.mozilla.org/mozilla-central/rev/2fb74c67b0c5#l11.40

Meant we also bailed out from user font prioritization for system fonts.

It's unclear whether that's really the best behavior but since the
intention of the regressing patch was not to change behavior, preserving
the old behavior seems better.

Differential Revision: https://phabricator.services.mozilla.com/D131899

Bug 1742393 - Correctly report animation status of pseudo-elements that are not stored in the parent element. r=hiro

We allow animating pseudo-elements like ::-moz-progress-bar (and we
treat them like regular elements).

Ideally we should store animations for these in the parent element as
well, so they survive reframes and such. But treating them as regular
elements right now means that we do animate them, but we never update
animations for them correctly because wrapper.rs assumed them to be
non-animatable.

Since it seems reasonable to keep allowing the animations to happen,
let's just correct the update code and add a test.

Differential Revision: https://phabricator.services.mozilla.com/D131794