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
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
This patch adds the animation-timeline longhand property. For
shorthand, we will do that in the next patch.
This patch includes the aut-generated code in
devtools/shared/css/generated/properties-db.js, by `./mach devtools-css-db`.
Note:
1. we will use this property in Bug 1676791. For now, only make sure
we parse it and serialize it correctly.
2. The syntax of animation-timeline may be updated, based on the spec
issue: https://github.com/w3c/csswg-drafts/issues/6674.
However, it's not a big problem to update it later, so we still can
prototype this property based on the current version of spec.
Differential Revision: https://phabricator.services.mozilla.com/D126450
@counter-style/@font-face/@scroll-timeline need similar fixes, but tests
for those haven't been synced yet so waiting for that before writing
them.
Differential Revision: https://phabricator.services.mozilla.com/D126616
I'm not aware of any reason we shouldn't do this, as it is interoperable
with other browsers, and it causes compat issues from sites that forget
to use the prefixed version.
Note this removes some #[parse(aliases)]. These only affect devtools
autocomplete behavior, and we avoid autocompleting -moz-prefixed
keywords when possible, so even though it's a slight behavior change,
it's worth it.
Differential Revision: https://phabricator.services.mozilla.com/D126718
Note that the crash reason is sanitized so we're not exposing anything
sensitive.
I think my patch just changed the signature of the stack, as it didn't
change anything related to guards or what not. But without knowing why
is failing or a repro it's hard to know what's going on.
Printing the address at list would give us some indication of what might
be going wrong (perhaps we're using a static lock when we don't expect
one or such?).
Differential Revision: https://phabricator.services.mozilla.com/D125948
Emilio Cobos Álvarez
Mats Palmgren
Noemi Erli
stransky
Mike Hommey
Boris Chiou
Butkovits Atila
Glenn Watson
Harry Twyford
Cristian Tuns
Stephen A Pohl