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
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 "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
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
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
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 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
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
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
.fallback is always the default font for the lang group unless we're a
system font (in which case it's "none").
The only reason we need that is because we need to react to
language changes (which affect the initial font).
Simplify the model a bit doing the language lookup in gfxTextRun (this
should avoid allocating a few nsStyleFont structs too.
Depends on D130732
Differential Revision: https://phabricator.services.mozilla.com/D131312
This seems like more sensible behavior. We have another use of
only_generic(), but that affects font sizing and other browsers agree
with us there:
<div style="font-family: monospace">Should be 13px</div>
<div style="font-family: something, monospace">Should be 16px</div>
So not touching that one.
Differential Revision: https://phabricator.services.mozilla.com/D130732
Apparently using transparent borders and outlines is a common
accessibility technique to make those visible in HCM.
Bug 1740924 comment 9 seemed to indicate we were the only browser
rendering those browsers, but I just confirmed that Edge at least does
show them.
Keep respecting system colors as that's per spec.
Differential Revision: https://phabricator.services.mozilla.com/D131412
This causes (among other things) pages to be dark when using regular
windows system colors and forcing colors to "always", which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D131165
In some platforms (like macOS, windows dark mode, android, and some gtk
themes) the foreground selection color might be `currentcolor`, and that
doesn't generally guarantee enough contrast with the attention
background.
Remove HeadlessLookAndFeelGTK's handling of this color since it's
useless (always overridden by prefs in all.js)
Differential Revision: https://phabricator.services.mozilla.com/D130617
Behind a pref for now. Given these selectors do nothing on non-chrome
documents (they just don't match) it seems worth trying.
A cursory search seems to indicate they're not used for UA detection or
something like that (or at least I haven't found such an usage).
Differential Revision: https://phabricator.services.mozilla.com/D130736
Use the same document state mechanism we have for :moz-locale-dir. Also,
simplify the setup of the later to be the same as :dir(), allowing the
matching code to be less repetitive.
This should fix some flakiness in chrome mochitests, but we have no existing
tests for these pseudo-classes more generally and since they're just
chrome-only I'm not super-excited about adding more.
Differential Revision: https://phabricator.services.mozilla.com/D130735
This I noticed while working on the following patches. Shouldn't have
any behavior change: the behavior does in fact match the element state
flag semantics correctly if we do this. We did split the dir flags into
two element bits a while ago.
:not(:dir()) still behaves correctly of course, and we have tests for that.
Differential Revision: https://phabricator.services.mozilla.com/D130734
