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
This is just cleanup. We have better ways to run code on shutdown (the pointer
to the theme object gets cleared on shutdown anyways).
Depends on D114697
Differential Revision: https://phabricator.services.mozilla.com/D114698
This is just cleanup. We have better ways to run code on shutdown (the pointer
to the theme object gets cleared on shutdown anyways).
Depends on D114697
Differential Revision: https://phabricator.services.mozilla.com/D114698
It's not like our menupopups look anything like native ones other than
the color, anyways, so this will allow us to improve all our menupopups
at the same time.
Differential Revision: https://phabricator.services.mozilla.com/D113556
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 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
The Linux styles match Adwaita trunk[1], so it's a bit smaller than the
native ones but I think that's fine (it matches other themes more
closely, like Arc).
On OSX the system color needs to be tweaked (will do in a follow-up)
since it is windows-style yellow right now, which is rather ugly. But
this is a progression regardless.
[1]: https://gitlab.gnome.org/GNOME/gtk/-/issues/3352
Differential Revision: https://phabricator.services.mozilla.com/D107548
There's no reason we should need an scrollbar box to query the size of a
scrollbar. I plan to use this in the following patch to make the size of a
resizer not vary depending on whether the container has scrollbars or not,
which is what ultimately causes the reftest failure.
Differential Revision: https://phabricator.services.mozilla.com/D103302
This doesn't hold with fractional scale values. Right now GTK truncates
the scale factor, Windows rounds, and non-native theme rounds as well.
With this native theme will propagate correctly the floating point
values.
I tried to not change behavior meaningfully in any of the other themes,
mostly to avoid risk. GTK and Windows can be trivially tweaked to
support fractional scale factors properly if we wanted to, but seems
better to not do that as part of this patch.
Depends on D98099
Differential Revision: https://phabricator.services.mozilla.com/D98100
nsNativeThemeGTK::GetGtkWidgetAndState looks as if it should write to
out-parameters `*aState` and `*aWidgetFlags` any time it returns `true`. But
it is possible to observe that `*aWidgetFlags` is uninitialised when `true` is
returned. This simple patch zero-initialises `*aWidgetFlags` at the start, in
the same way that `*aState` is already zero-initialised at the start.
Differential Revision: https://phabricator.services.mozilla.com/D90697
This allows it to be forward-declared (while a nested class cannot be),
such that headers files that use RectCallback by pointer or reference
do not need to include nsLayoutUtils.h.
This avoids including nsLayoutUtils.h in nsRange.h.
Differential Revision: https://phabricator.services.mozilla.com/D91685
Cleans up the code a bit to make actually used fallback code easier to spot
and update the required GTK version so deprecation warnings are more accurate.
Also make `gdk_window_set_opaque_region` always available - we can now assume
it to be present in all supported versions.
Differential Revision: https://phabricator.services.mozilla.com/D82804
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
This makes inputs not remain very big at small font sizes, which is
needed for compat both with other browsers and platforms, while keeping
the right native appearance at normal / large font sizes.
Differential Revision: https://phabricator.services.mozilla.com/D76256
Turns out we did have a hook for this already! But it is used to draw or
not inner button styles, so not quite equivalent.
I had to expand the amount of things it applies to because buttons and
such do paint focus indicators in all widgets. This patch could cause
some undesired outlines in some widgets. I hope not (I tried to audit to
the best of my knowledge), but in that case they'd be just more values
to add to the list.
Differential Revision: https://phabricator.services.mozilla.com/D74733
Turns out we did have a hook for this already! But it is used to draw or
not inner button styles, so not quite equivalent.
I had to expand the amount of things it applies to because buttons and
such do paint focus indicators in all widgets. This patch could cause
some undesired outlines in some widgets. I hope not (I tried to audit to
the best of my knowledge), but in that case they'd be just more values
to add to the list.
Differential Revision: https://phabricator.services.mozilla.com/D74733
That is, so that the select dropdown button always take the size of a
native scrollbar rather than a potentially custom scrollbar.
Differential Revision: https://phabricator.services.mozilla.com/D73261
gfx::Color is currently misused in many places. The DrawTargets expect
the color space to be in device space, e.g. what we are actually going
to draw using. Everything sitting above generally deals with sRGB, as
specified in CSS. Sometimes we missed the conversion from sRGB to device
space when issuing draw calls, and similarly sometimes we converted the
color to device space twice.
This patch splits the type in two. sRGBColor and DeviceColor now
represent sRGB and device color spaces respectively. DrawTarget only
accepts DeviceColor, and one can get a DeviceColor from an sRGBColor via
the ToDeviceColor helper API. The reftests now pass with color
management enabled for everything (e.g. CSS) instead of just tagged
raster images.
There will be a follow up patch to enable color management everywhere by
default on all supported platforms.
Differential Revision: https://phabricator.services.mozilla.com/D64771
--HG--
extra : moz-landing-system : lando
This should be less confusing. This is not supported outside of chrome:// or
user-agent stylesheets so we can name this however we want.
Differential Revision: https://phabricator.services.mozilla.com/D65605
--HG--
extra : moz-landing-system : lando
This allows testing much more easily.
There are some edge cases with native theme changes and such (ThemeChanged and
co assume there's only one theme per process). But I don't think they matter
much for our use cases.
Differential Revision: https://phabricator.services.mozilla.com/D65162
--HG--
extra : moz-landing-system : lando
I don't think we want to keep the ugly widget hacks forever. Let me know if
you'd rather keep the property behind a pref but I don't think there's a point
in doing that.
Differential Revision: https://phabricator.services.mozilla.com/D62649
--HG--
extra : moz-landing-system : lando
I don't think we want to keep the ugly widget hacks forever. Let me know if
you'd rather keep the property behind a pref but I don't think there's a point
in doing that.
Differential Revision: https://phabricator.services.mozilla.com/D62649
--HG--
extra : moz-landing-system : lando
Jonathan Kew
Emilio Cobos Álvarez
Csoregi Natalia
stransky
Narcis Beleuzu
Bogdan Tara
Markus Stange
Julian Seward
Botond Ballo
Robert Mader
Cameron McCormack
Cosmin Sabou
Oana Pop Rus
Simon Giesecke
Andrew Osmond