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 avoids adding yet another parameter for the light/dark
color-scheme.
This shouldn't have any behavior change, but is a prerequisite to
implement dark form controls on the non-native theme.
Differential Revision: https://phabricator.services.mozilla.com/D127482
Also, make the same change to nsPresContext::GetTextInputHandlingWidget and
TextComposition::GetWidget, which are essentially aliases/wrappers for this
function.
This patch shouldn't change behavior at all, aside from:
* optimizing away some redundant reference counting and widget-lookups
* delaying some nsIWidget::Release() calls, which will now happen after we're
actually done using the object, instead of happening when the getter
completes. (It's unlikely this impacts behavior, because there are other
objects that are keeping the nsIWidget instance alive.)
Motivation / "wins" from this patch:
* nsPresContext::GetRootWidget already works with a refcounted pointer
internally. Before this patch, it drops the reference before returning the
pointer. This is a bit suspect and would cause security issues, in the
unlikely event that this were the last strong reference to the object. It
can just as easily/efficiently transfer the strong reference to the caller,
and let the caller determine when to release it.
* Many of the callers were already storing the return value in nsCOMPtr, which
meant that they were incurring an additional AddRef/Release when
populating/destructing that smart pointer. Now they can just take ownership
of the already_AddRefed return value and avoid redundnat refcount-churn.
* For the callers that weren't storing the return value in nsCOMPtr, some of
them were calling this getter twice in a row (once to test for truthiness and
once to use the known-truthy value). This was wasteful, both from the
repeated lookup-work (since the function isn't a trivial getter), and from
repeated refcount-churn. This patch collapses these repeat-calls to a single
call, avoiding those inefficiencies.
Differential Revision: https://phabricator.services.mozilla.com/D127180
Also, make the same change to nsPresContext::GetTextInputHandlingWidget and
TextComposition::GetWidget, which are essentially aliases/wrappers for this
function.
This patch shouldn't change behavior at all, aside from:
* optimizing away some redundant reference counting and widget-lookups
* delaying some nsIWidget::Release() calls, which will now happen after we're
actually done using the object, instead of happening when the getter
completes. (It's unlikely this impacts behavior, because there are other
objects that are keeping the nsIWidget instance alive.)
Motivation / "wins" from this patch:
* nsPresContext::GetRootWidget already works with a refcounted pointer
internally. Before this patch, it drops the reference before returning the
pointer. This is a bit suspect and would cause security issues, in the
unlikely event that this were the last strong reference to the object. It
can just as easily/efficiently transfer the strong reference to the caller,
and let the caller determine when to release it.
* Many of the callers were already storing the return value in nsCOMPtr, which
meant that they were incurring an additional AddRef/Release when
populating/destructing that smart pointer. Now they can just take ownership
of the already_AddRefed return value and avoid redundnat refcount-churn.
* For the callers that weren't storing the return value in nsCOMPtr, some of
them were calling this getter twice in a row (once to test for truthiness and
once to use the known-truthy value). This was wasteful, both from the
repeated lookup-work (since the function isn't a trivial getter), and from
repeated refcount-churn. This patch collapses these repeat-calls to a single
call, avoiding those inefficiencies.
Differential Revision: https://phabricator.services.mozilla.com/D127180
We need to use standins for CSS-accesible colors in high contrast mode
(when appropriate) so that the CSS color matches the one in forms.css.
But this is not needed for e.g. scrollbar colors, which are not
CSS-accessible. So shuffle around the checks so that we account for
that as we should.
Differential Revision: https://phabricator.services.mozilla.com/D125830
With the non-native theme we don't need filter for this to affect
"native" inputs, we can just implement the logic in nsNativeBasicTheme
instead.
A bit unfortunate that we need that special-case, but it seems better
than using filter, which can break websites due to it creating an
stacking context.
I _think_ there are tests that I need to adjust for this change, but if
not I'll write some.
Keep the current behavior behind a pref just in case.
Differential Revision: https://phabricator.services.mozilla.com/D125232
With the non-native theme we don't need filter for this to affect
"native" inputs, we can just implement the logic in nsNativeBasicTheme
instead.
A bit unfortunate that we need that special-case, but it seems better
than using filter, which can break websites due to it creating an
stacking context.
I _think_ there are tests that I need to adjust for this change, but if
not I'll write some.
Keep the current behavior behind a pref just in case.
Differential Revision: https://phabricator.services.mozilla.com/D125232
I tied it to the use-theme-accent bit in non-native-theme just for
convenience (so that form controls just react to this).
This works nicely, but I didn't turn this on by default because the
accessiblecaret images are hardcoded-blue pngs, and they look ugly
without being the same color as the native accent.
Differential Revision: https://phabricator.services.mozilla.com/D120898
The accent-color computation right now chooses between black and white,
which is not ideal.
I tried to make it so that authors could choose the foreground colors in
the linked CSSWG issue from the comment, but that didn't go anywhere.
I think choosing a contrasting color that is in-line and contrasting
enough with the accent-color chosen by the page when darkening is better
than just black or white.
If we want the black-or-white behavior we can just change
layout.css.accent-color.target-contrast-ratio to something large enough.
https://accent-color.glitch.me/ is a nice playground to see this patch
in action.
Differential Revision: https://phabricator.services.mozilla.com/D120723
(Like for printing with backgrounds disabled).
Otherwise layout darkens our foreground colors etc, and that causes contrast to
be poor.
Since the point of not painting backgrounds is saving ink, using the
regular colors seems fine.
Differential Revision: https://phabricator.services.mozilla.com/D118276
While this doesn't match traditional Gecko behavior, the non-native
theme has much more opinionated focus outlines so I think this makes
sense.
It also matches Safari and Chrome, afaict.
Differential Revision: https://phabricator.services.mozilla.com/D116831
While this doesn't match traditional Gecko behavior, the non-native
theme has much more opinionated focus outlines so I think this makes
sense.
It also matches Safari and Chrome, afaict.
Differential Revision: https://phabricator.services.mozilla.com/D116831
Right now we paint scrollbars using gtk in nsNativeThemeGTK, and that
makes them look a bit inconsistent if the non-native implementation ends
up drawing them differently. I think scrollbars should look the same
regardless of where they're drawn.
This simplifies the code, and also brings proper scrollbar-{width,color}
support to the native theme, which is nice because Thunderbird uses it
if you use a theme there.
I opted for removing the code, but let me know if you'd rather keep it
behind the widget.non-native-theme.enabled pref or such.
Differential Revision: https://phabricator.services.mozilla.com/D114699
As in that case it probably doesn't have enough contrast. This is drive-by
since, while I was looking at that GTK theme, the scrollbars are monochrome.
Differential Revision: https://phabricator.services.mozilla.com/D114394
This improves the rendering of youtube.com on Windows, and I think should be uncontroversial.
scrollbar-color: transparent transparent will still get you the fully transparent scrollbar.
Differential Revision: https://phabricator.services.mozilla.com/D111137
This improves the rendering of youtube.com on Windows, and I think should be uncontroversial.
scrollbar-color: transparent transparent will still get you the fully transparent scrollbar.
Differential Revision: https://phabricator.services.mozilla.com/D111137
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
This is a follow-up that I thought was worth doing, but let me know if
you disagree or what not. I think this produces the best results:
* For light pages, we still get light scrollbars for the track, but the
active thumb still uses the dark theme highlight color.
* For dark pages, we again still use the themed highlight color for the
thumb, and we use dark scrollbar colors elsewhere like we do now.
Again, let me know if you think this is not worth it, or is too much, or
what not. I've tested this on a decent range of popular GTK themes and
it looks like a clear progression to me.
Differential Revision: https://phabricator.services.mozilla.com/D110203
So that they work sorta similar to the native ones. This is intended
mostly for testing, but hey, if someone is motivated enough...
I haven't tracked the native gtk overlay scrollbar durations down,
someone motivated enough could do that if they wanted to. But this seems
close enough.
Differential Revision: https://phabricator.services.mozilla.com/D110192
(When not following the frame's border radius of course)
This makes stuff like:
data:text/html,<input style="border-color: lightgrey">
More aesthetically pleasing when focused, and we still keep the square
inside the outline (this is what Safari does).
Differential Revision: https://phabricator.services.mozilla.com/D109680
This is caused by a minor issue with WebRender disabled where the radii
was slightly off because it wasn't accounting for the deflation of the
rect.
Differential Revision: https://phabricator.services.mozilla.com/D109206
This is a relatively easy way to improve the rendering with the
non-native theme while not regressing anything.
In the future, once non-native-theme is shipped and default everywhere,
I think we could provide something like:
bool nsITheme::GetShadowRect(nsIFrame*, StyleAppearance, LayoutDeviceRect&, RectCornerRadii&)
or such, where we can provide a precise rect + radii, and we would avoid
painting the shadow if the function returned false. That would allow us
to remove the native theme box shadow code path, and avoid WR fallback,
all at once.
Differential Revision: https://phabricator.services.mozilla.com/D109209
