Make both the light and dark colors less opaque too, since even in light
mode it looks very off IMO for stuff like:
data:text/html,<body bgcolor=grey><input>
Differential Revision: https://phabricator.services.mozilla.com/D129302
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
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
(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
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
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
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
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
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
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
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
The only thing missing now are things that draw arrows / checkmarks.
Make the disabled range thumb opaque, to avoid dealing with clipping
(also matches all other browsers, fwiw).
Differential Revision: https://phabricator.services.mozilla.com/D106011
The only thing missing now are things that draw arrows / checkmarks.
Make the disabled range thumb opaque, to avoid dealing with clipping
(also matches all other browsers, fwiw).
Differential Revision: https://phabricator.services.mozilla.com/D106011
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
We basically use a couple primitives to draw these
(PaintRoundedRectWithRadius, FillRect), so making the code a bit generic
implementing stuff with WebRender seems straight-forward.
I've kept using the fallback codepath for the bits that draw complex
paths like arrows and such, but the rest of the things should work with
this patch.
A thing I'm not too happy about is the scrollbar painting setup (requires a lot
of boilerplate), but modulo template hacks make nsNativeBasicTheme a template
that receives its super class as a parameter or something) it seems hard to do
better.
Differential Revision: https://phabricator.services.mozilla.com/D105931
This matches closer what Chrome and Safari do (Safari paints outside of
the box when this happens, but the layout box still respects the
author), see:
data:text/html,<button style="padding: 0; width: 0">
data:text/html,<input type=checkbox style="width: 0">
Etc. For checkboxes, this matches what OSX does, too.
Since we still want checkboxes to be slightly larger than what they'd be
otherwise, we add a hook to tweak it when non-native theme is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D105798
This matches closer what Chrome and Safari do (Safari paints outside of
the box when this happens, but the layout box still respects the
author), see:
data:text/html,<button style="padding: 0; width: 0">
data:text/html,<input type=checkbox style="width: 0">
Etc. For checkboxes, this matches what OSX does, too.
Since we still want checkboxes to be slightly larger than what they'd be
otherwise, we add a hook to tweak it when non-native theme is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D105798
This makes form controls match the rest of the GTK theme like selection
colors, etc.
An alternative to this would be to just use non-native colors on GTK for
all content, but that seems somewhat unfortunate and we do the right
thing for scrollbars so...
I've tried on a variety of themes and this looks nice so far.
Differential Revision: https://phabricator.services.mozilla.com/D104496
outline-style: auto might show up in non-themed controls and such, and
the double-outline there might look ugly.
Following border-radius would be an extra improvement for the reddit
case, but no platform does it currently (Safari on macOS does it), so
let's consider that in a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D104214
This is based on the windows implementation and has two nice things:
* Makes scrollbar-color react to active / hover state, like on Windows.
* Implements dark scrollbar support.
Differential Revision: https://phabricator.services.mozilla.com/D103969
This seems to come from bug 1179780, but custom scrollbars shouldn't
have this requirement, and it's kind of artificial anyway.
Differential Revision: https://phabricator.services.mozilla.com/D103692
Emilio Cobos Álvarez
Stephen A Pohl
criss
Butkovits Atila
Cosmin Sabou
smolnar
Noemi Erli