(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
This also uncovered a minor issue with WebRender disabled where the
radii was slightly off because it wasn't accounting for the border.
Differential Revision: https://phabricator.services.mozilla.com/D109206
This prevents contrast issues with high contrast themes when the page only
specifies some of the colors (which is an issue which we have historically
had on GTK with dark themes for a long time).
Feel free to push back on this if you prefer this, as on GTK we force a light
theme on content anyways, but this is a problem on windows for users that use a
high contrast theme but allow pages to override colors.
Differential Revision: https://phabricator.services.mozilla.com/D108324
Using the same color for the track and the meter chunk is not going to
fly of course...
In high contrast, make the colors consistent with <progress>, which
seems like a reasonable thing to do.
Differential Revision: https://phabricator.services.mozilla.com/D108347
I wonder if we could do something more fancy with the animation than
QueueAnimatedContentForRefresh, which is timer based, like a
transform-like animation that WebRender could run or something, but this
is probably good enough for now.
Depends on D108335
Differential Revision: https://phabricator.services.mozilla.com/D108336
The progress chunk already has the right size, but it's easier to get
the right clipping if we just paint it as part of the progress bar.
This is much like we paint the range track and thumb. We apply the
native appearance atomically so this should be fine.
Differential Revision: https://phabricator.services.mozilla.com/D108335
Mostly use matching foreground / background colors. Buttonface is the
counterpart of Buttontext, and Highlightext the counterpart of Highlight.
This fixes contrast of checkboxes and radio buttons for example, and a couple
other contrast issues with light themes specially.
Differential Revision: https://phabricator.services.mozilla.com/D108319
Linux can also have high contrast (and mac, if you tweak prefs, but
let's assume that doesn't happen), so no reason we shouldn't share this
code.
One related simplification while I was doing this code move is that I
managed to remove the scrollbar "border" code. Turns out that Windows
was overriding ComputeScrollbarColors so that border and track colors
were always the same, and Linux was ignoring the border anyways, so with
this we can simplfiy the implementation a bit (as the Linux scrollbar
track / corner code can be shared with Windows now).
Differential Revision: https://phabricator.services.mozilla.com/D107863
data:text/html,<input type=checkbox checked disabled>
Has a weird double border because the DrawTarget codepath fills and
strokes the same path, which is fine if the border is opaque, but not
otherwise.
Since this is the only use for a non-opaque border that we have, I
think, dealing with it on the caller seems a bit simpler. But let me
know if you want me to fix it more generally in
PaintRoundedRectWithRadius. I think for the semi-transparent border
case we'd need to create two paths, one for the background and one for
the border, which is a bit unfortunate.
The webrender codepath does the right thing, but of course that doesn't
get used for checkboxes.
Differential Revision: https://phabricator.services.mozilla.com/D107815
This used to be the case (for default-sized radio buttons anyways)
before bug 1693688 (since GetMinimumWidgetSize returns a
LayoutDeviceIntSize, which rounded).
With the previous patch we never see uneven borders, but the radio might
be e.g. one pixel taller than its width, which also looks odd. So
truncate to device pixels to avoid it.
Differential Revision: https://phabricator.services.mozilla.com/D107810
This isn't really an uneven border (because we snap border widths
correctly); this is the textfield border snapping differently than the
outline, actually, in a way such that the outline shows underneath. We
use negative offsets to try to cover the border but that breaks in this
case.
I thought of two ways to fix it, but this one looks slightly more
future-proof (and simpler), see the comment in ComputeBorderColor. Let
me know if you want me to go the other way (snapping offsets instead) or
both, actually.
The transparent border uncovered that the radius was slightly off, and
also that I forgot to snap the auto-style outline width properly, so I
fixed those drive-by too (without the first one stuff looks off
otherwise, at least, the second one I could move).
Differential Revision: https://phabricator.services.mozilla.com/D107287
This isn't really an uneven border (because we snap border widths
correctly); this is the textfield border snapping differently than the
outline, actually, in a way such that the outline shows underneath. We
use negative offsets to try to cover the border but that breaks in this
case.
I thought of two ways to fix it, but this one looks slightly more
future-proof (and simpler), see the comment in ComputeBorderColor. Let
me know if you want me to go the other way (snapping offsets instead) or
both, actually.
The transparent border uncovered that the radius was slightly off, and
also that I forgot to snap the auto-style outline width properly, so I
fixed those drive-by too (without the first one stuff looks off
otherwise, at least, the second one I could move).
Differential Revision: https://phabricator.services.mozilla.com/D107287
