This makes our menus closer to GTK4, and depends less on the native menu
rendering etc. Thunderbird already does this to some extent.
Leave the old code behind a pref for now (just in case). Also fix some
code in nsNativeTheme::GetContentState (fixes rendering of radio menu
items).
Differential Revision: https://phabricator.services.mozilla.com/D175664
This seems to be here since nsTextControlFrame has a meaningful
baseline, but it doesn't make much sense to me:
* Baseline is a block axis, not inline axis measurement.
* It doesn't call into the base class which seems clearly a bug (though
the intrinsic isize of the input is ~fixed, doesn't depend on font
metrics, so it's probably ok).
My guess is that it was intended to be a debug-only check so that we
could detect stale baseline values.
Just remove this, and replace it by a non-fatal assert as it's done
elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D175745
This isn't needed for nsTextControlFrame because its ComputeAutoSize
implementation doesn't return an unconstrained line-height for inputs,
so we never end up in the UNCONSTRAINEDSIZE case, but it's needed for
date/time inputs.
Use GetLineHeight while at it, since it's the inflated line-height which
is what we want, and may be cached so we can avoid computing it.
Maybe in the future we can make date/time inputs just use
nsTextControlFrame, which would prevent this from happening in the
future.
Depends on D175745
Differential Revision: https://phabricator.services.mozilla.com/D175746
This adds the new infrastructure for rendering masked primitives
and uses it for simple rectangle primitives. Follow up patches
will port other primitives to it (and transformed rectangles).
Instead of rendering an alpha mask and then applying that during
picture cache rendering of content, the underlying content is
drawn to an off-screen surface, and the mask is applied on
top of that via multiplicative blending.
This is particularly helpful for applying masks to dynamically
rendered pictures in future, as we can apply the mask over the
already rendered picture without allocating an extra surface.
Since the content and mask is rendered together to a surface,
we can take advantage of this in future by caching the result
in the texture cache, rather than a temporary render target.
This means we don't need to redraw clip masks for this content
each time the surrounding area is invalidated.
Since the clip-mask is rendered in to the off-screen surface,
it is cheaper and simpler to composite the content in to the
main scene, avoiding an extra texture fetch and some tricky
fragment shader logic to sample the correct part of the mask.
To reduce the number of off-screen pixels that get drawn, the
system supports splitting the content up in to a series of
segments. This can either be a 9-patch, for the simple and
common case of a single rounded clip, or a tile grid across
the primitive. The tile grid can make it much faster to apply
large image masks, where there are often large areas that we
can determine are not affected by the mask image.
Differential Revision: https://phabricator.services.mozilla.com/D173095
We don't modify the clip in their scope, so we don't really need them,
afaict.
Bug 1413073 removed the clearing, but not the restore calls.
I was looking at these because of bug 1827428.
Differential Revision: https://phabricator.services.mozilla.com/D175408
Webrender doesn't seem to handle them well. This of course will affect the balance of making things active, but hopefully this is a good trade off.
Differential Revision: https://phabricator.services.mozilla.com/D165726
This is a Selectors-4 enhancement to the spec for the :lang() pseudo-class.
It seems Safari has been shipping this behavior for some time.
Differential Revision: https://phabricator.services.mozilla.com/D174999
Disable OMTA support for now. We have to make sure what should we do when
the subject is scrolled to "out of view" on the compositor, in Bug 1818346.
And we have to make sure view-timeline-inset animation work well on the
compositor.
Also, update tests,
1) timeline-offset-keyframes-hidden-subject.html, and
2) view-timeline-keyframe-boundary-interpolation.html,
to avoid js error because Gecko doesn't expose Animation object with
scroll-timeline or view-timeline.
And update test, view-timeline-lookup.html, because scroll progress timelines
take precedence over view progress timelines (i.e. choose the matched scroll
progress timeline first), per the spec in
https://drafts.csswg.org/scroll-animations-1/#timeline-scope.
Differential Revision: https://phabricator.services.mozilla.com/D170004
However, We don't lookup the object of view-timeline-name for CSS animations
until we finish its implementation in the patch series.
Note: this patch assumes `view-timeline-inset` is not animatable. We will
fix it in Bug 1817073.
Differential Revision: https://phabricator.services.mozilla.com/D170001
Emilio Cobos Álvarez
Timothy Nikkel
Ting-Yu Lin
Hiroyuki Ikezoe
Glenn Watson
Iulian Moraru
Jonathan Kew
Cristian Tuns
Dan Robertson
Emily McDonough
Robert Longson
Norisz Fay
Andi-Bogdan Postelnicu
Mirko Brodesser
Lee Salzman
Natalia Csoregi
Florian Quèze
Boris Chiou
Narcis Beleuzu