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
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
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
We add scroll-timeline rule into the stylesheet rule type, and add a new
perference to protect it: layout.css.scroll-linked-animations.enabled.
We will use this perference for animation-timeline property as well.
Differential Revision: https://phabricator.services.mozilla.com/D125765
We need to compute the anonymous name on the fly while building the
CascadeData, otherwise we may see the same layer rule in two places due
to stylehseet sharing and make them incorrectly share a name.
Differential Revision: https://phabricator.services.mozilla.com/D125175
I'll add some tests before enabling. Also, WebKit folks (who have
implemented cos() / tan() / sin()) said they will upstream their tests
to WPT, so I'll extend those with the inverse functions before landing
as well.
Differential Revision: https://phabricator.services.mozilla.com/D124990
The specifics of how this is going to work are still getting spec'd /
discussed in https://github.com/w3c/csswg-drafts/issues/6576, but this
allows DevTools to work fine and the feature to be complete enough for
Nightly experimentation (with the other in-flight patches).
Otherwise devtools crashes when trying to inspect pages that use them.
Differential Revision: https://phabricator.services.mozilla.com/D124656
When we had:
@layer A.B;
We were registering "A" and "B", not "A" and "A.B", which was the intention.
Fix is trivial.
Depends on D124620
Differential Revision: https://phabricator.services.mozilla.com/D124621
This makes layer order use a fixed set of bits per nesting level, to "reserve"
bits for children before they are registered.
See the comment in LayerOrder for the implementation limits it imposes, and
potential alternatives if these limits are not enough (but I think they should
be).
Enable the tests, as they mostly pass now (commit incoming to fix the remaining
ones).
Differential Revision: https://phabricator.services.mozilla.com/D124620
This works modulo the existing nested layer order bug. Will be covered
by WPT /css/css-cascade/layer-import.html once the feature is enabled (I
can probably enable it right away for those tests, but I'd rather fix
the obvious bugs first).
Differential Revision: https://phabricator.services.mozilla.com/D124538
Same, I want to land this separately to see if it affects
micro-benchmarks. If so, we might want to pack the layer order
_somewhere_ (though in this case I'm not sure where, tbh).
With this, layer rules should have an effect on the page. There are
a few things missing before being able to enable them:
* Fix nested layer order in some cases (when parent layers are declared
out of order, see the previous commit mentioning this).
* Some kind of OM representation, perhaps.
* Tests of course, which are coming in bug 1728722 and bug 1727276.
But this should be enough to allow playing with them.
Depends on D124337
Differential Revision: https://phabricator.services.mozilla.com/D124338
I want to land this separately because we might want to get smarter with
the size of the Rule struct (maybe restricting layer order to a u8 per
scope and packing it with the source order, since 255 layers seem
plenty), but I'd rather do the obvious thing for now.
Depends on D124336
Differential Revision: https://phabricator.services.mozilla.com/D124337
This code is really hot, and we've had perf regressions in the past for
introducing function calls in the hot path.
After the previous patch, add_rule is recursive and thus it can't be
inlined, causing a function call for each CSS rule.
This reduces the overhead by making the function take a rule list
instead, causing a function call per rule _list_, which should be
unnoticeable in practice.
Depends on D124335
Differential Revision: https://phabricator.services.mozilla.com/D124336
