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
Note that element.clone() is just copying a couple pointers.
Have a single place where we compute the next element and check for linky-ness.
This saves a couple checks (very very minor win in the micro-benchmark I've
been looking at, but consistent).
Depends on D145484
Differential Revision: https://phabricator.services.mozilla.com/D145485
This makes the inner function much smaller which improves selector-matching
performance very mildly for the benchmarks I've been looking at. Also, this
should help selector matching on quirks mode by only doing this when we
actually find :hover / :active pseudo-classes.
Differential Revision: https://phabricator.services.mozilla.com/D145484
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
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
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
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
Instead, make the behavior consistent across all <length-percentage>
values (by truncating instead of rounding). This is the already-existing
behavior for calc() and percentages, but with this patch we also apply
it to plain length-flavored <length-percentage> values (this is needed
to avoid regressing things like bug 989802).
Regular <length>s keep rounding, to preserve existing behavior. We can
consider changing that in a follow-up if need be.
Differential Revision: https://phabricator.services.mozilla.com/D143857
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
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
This doesn't change behavior on its own, but the current code introduces
some minor floating point error which we can avoid, and which would
cause failures with the other patch on the bug.
Differential Revision: https://phabricator.services.mozilla.com/D143942
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
I forgot we were doing this "revert-or-initial" shenanigans (which is needed
for stuff like link colors to be honored), so we need to early-return.
Use a more explicit test rather than a reftest for this.
Differential Revision: https://phabricator.services.mozilla.com/D142063
They are just convenience for :root[lwthemetextcolor="light"] (and dark,
respectively), but they generally shouldn't be used for dark mode
theming. In the past it was the only way to do it but now we have
prefers-color-scheme.
While at it, change lwthemetextcolor to be "lwtheme-brighttext" for
consistency with similar code we have for popups etc, and move it to
_setDarkModeAttributes.
While at it, remove layout.css.moz-lwtheme.content.enabled (which is
false always, we unshipped these from content successfully).
Differential Revision: https://phabricator.services.mozilla.com/D141593
The flags stylo cares about reading and writing potentially at the same
time are disjoint, so there's no need for any strong memory ordering.
Differential Revision: https://phabricator.services.mozilla.com/D141829
The flags stylo cares about reading and writing potentially at the same
time are disjoint, so there's no need for any strong memory ordering.
Differential Revision: https://phabricator.services.mozilla.com/D141829
This should be cheap and gives us a lot of memory savings for the page
on the bug, by deduplicating the inherited properties between parent and
children.
WebKit implements a similar optimization.
Differential Revision: https://phabricator.services.mozilla.com/D140826
If a name is not in self.seen, it means we've inherited it from our
parent. That in turn means that it can't have any variable reference
(because we inherit the computed variables) and we can skip the work of
traversing it, as we'd hit the early-return in traverse() anyways.
This doesn't fix the memory usage issue of the page on the bug, which
has a giant list of properties on the root and then a custom property
specified on all elements, but should significantly reduce the time we
spend iterating over custom properties for all those elements.
Differential Revision: https://phabricator.services.mozilla.com/D140825
As mentioned in bug 1747354, the location of the dist directory is
relied to be $topobjdir/dist, so just use that consistently rather
than getting it from a separate variable for rust build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D136556
As mentioned in bug 1747354, the location of the dist directory is
relied to be $topobjdir/dist, so just use that consistently rather
than getting it from a separate variable for rust build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D136556
If the theme is dark but user prefers light pages, the background of the
tabpanel should arguably be light, since it can be seen across some
navigations.
Expose a -moz-content-prefers-color-scheme media query to chrome pages
so that our UI can correctly query it (and remove the unused -moz-proton
atom while at it).
Differential Revision: https://phabricator.services.mozilla.com/D136437
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:
2b89cc4df4
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
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
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
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
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
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
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
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
This should mitigate the code size impact. Also make get_resolved_value
non-generic to avoid monomorphizing it multiple times.
Differential Revision: https://phabricator.services.mozilla.com/D130354
For now, use IntoIterator to figure the right type to add the bound.
If we need this on types that are iterable but don't provide
IntoIterator, we can add another attribute field or something.
Differential Revision: https://phabricator.services.mozilla.com/D129962
These are only used for frameset painting and the non-e10s <select>
dropdown focus codepath. We have other more appropriate standard
colors for this.
Differential Revision: https://phabricator.services.mozilla.com/D129992
The code introduced in the preceding patch deals with currentColor correctly,
so we should be able to do this now.
This uncovers a bug in the existing serialization code when a non-auto
text-decoration-thickness was used, caught by
css/css-text-decor/parsing/text-decoration-computed.html.
Differential Revision: https://phabricator.services.mozilla.com/D130018
This removes the various assumptions that the animation code does.
Code size might be a concern, we can optimize if it is a problem,
but let's do the obvious thing for now.
Differential Revision: https://phabricator.services.mozilla.com/D130017
And remove the autofill.background pref for 95 (or 96, depending on
when this lands) assuming nothing terrible causes us to turn it off on
94.
Differential Revision: https://phabricator.services.mozilla.com/D129988
This doesn't change behavior but will allow us to deduplicate some
logic given we compute the effective color-scheme in C++.
Differential Revision: https://phabricator.services.mozilla.com/D129744
The bitfield approach worked when the layer order was in pre-order, but
the spec was changed to make it work like post-order and I don't think
there's a way to keep it working like that, so keep the layer order in a
separate data structure that we look up when going from Rule to
ApplicableDeclarationBlock.
This is just a vector index operation so hopefully shouldn't be too bad.
This patch intentionally regresses @keyframe handling to some extent,
since we need a bit more complicated approach and it seemed worth
implementing in a separate patch.
Depends on D129380
Differential Revision: https://phabricator.services.mozilla.com/D129381
To more properly support Linux having a different default at runtime.
Expose the resolved value in appinfo for convenience, and use it in the
front-end as needed.
Differential Revision: https://phabricator.services.mozilla.com/D129004
We always use alpha visual for WebRender, and appearance: none is
unnecessary (root element has no intrinsic appearance).
Differential Revision: https://phabricator.services.mozilla.com/D128682
This bit is taken straight from D73454 (I reviewed it but I guess
another pair of eyes is ok, it's really straight-forward).
Co-authored-by: Nicklas Boman <smurfd@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D128679
We make it work on macOS by setting pointer-events: none + opacity: 0 rather
than visibility: hidden, and tweaking the caching setup to be Android-like.
Now that the scrollbars sheet is the same across platforms, move it to where
the rest of the UA sheets are. This way we guarantee that the RDM vs. Android
difference is less (just the ifdef at the top of the sheet).
Depends on D128084
Differential Revision: https://phabricator.services.mozilla.com/D128085
Apparently ActiveCaption/CaptionText/InactiveCaption/InactiveCaptionText
are supposed to be used for titlebars, so implement them properly and
remove the GTK-specific colors.
Differential Revision: https://phabricator.services.mozilla.com/D128028
The serialization of rotate should be updated to match the current spec.
1. If a rotation about the z axis (that is, in 2D) is specified, the property
must serialize as just an <angle>.
2. If any other rotation is specified, the property must serialize with an axis
specified. If the axis is parallel with the x or y axes, it must serialize
as the appropriate keyword.
Also, we need to handle the zero length vector separately because it is
parallel to every other vector but different from x axis, y axis, or z axis.
Differential Revision: https://phabricator.services.mozilla.com/D127747
ScrollSensitivity is not used by Gecko. Also remove some remnants
of the old code to combine scroll frames when display lists swap.
Differential Revision: https://phabricator.services.mozilla.com/D127609
For that:
* Tweak the standin system colors to match the non-native theme.
* Use those system colors for button and field backgrounds.
* Rename the "should use system colors" bit to "is high contrast",
which is what it really is (specially now that we use system colors
also in non-high-contrast).
Border colors and other colors like the <input type=range> and such
might need some extra tweaking perhaps, but this is a decent start and
looks good in https://crisal.io/tmp/form-controls.html afaict (dark mode
toggle needs the color-scheme pref enabled of course).
Differential Revision: https://phabricator.services.mozilla.com/D127533
This patch does three things:
* Unifies mac and gtk's buttonactivetext system colors (unships mac's from
content, but it was never meant to be exposed).
* Simplifies the forms.css rules, since <input type=color>'s color property
value doesn't affect its rendering in any meaningful way.
* Adds a buttonactiveface color, which we'll use to provide dark backgrounds
for buttons in Windows dark mode (and is good practice, since generally
every text system color should have a corresponding background).
So as-is it shouldn't change content-exposed behavior (except we stop exposing
the -moz-mac-buttonactivetext to content), but it's a worthy cleanup.
Depends on D127246
Differential Revision: https://phabricator.services.mozilla.com/D127259
There's only one meaningful usage of it, which is to disable native
appearance of the <input type=range> (the windows native theme is no
longer exposed to content).
<input type=range> is inconsistent with every other native widget, which
only disables native appearance if the author specifies backgrounds or
borders. So make it match literally all other widgets and simplify a bit
the code.
We had no tests for this special behavior, let me know if you think it's
worth adding one (but I don't feel very strongly about it).
Differential Revision: https://phabricator.services.mozilla.com/D127082
