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
The native theme doesn't enforce the size of the whole scrollbar. This is
important because if the scrollbar overflows the scroller we might suppress it.
This causes a variety of test failures with the non-native theme enabled. One
of the most glaring ones is:
http://wpt.live/css/css-flexbox/overflow-auto-006.html
We don't show scrollbars for the inline elements because their width is 50px
and the min scrollbar ends up being 51px (17 * 3) which is pretty unfortunate.
Instead, allow the thumb / scrollbar / track to shrink like the native theme.
Differential Revision: https://phabricator.services.mozilla.com/D106781
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
I thought we didn't support outline-offset on auto-style outline.
The rect we get is already inflated, so we just got to compute the
radius using that.
Differential Revision: https://phabricator.services.mozilla.com/D105125
Some GTK themes use very soft colors for selection backgrounds, using
darker colors for the text. This makes the tab and focus outlines in the
tab bar not have sufficient contrast with usual backgrounds.
I needed to do this for bug 1690778, but it seems worth doing it on the
front-end as well.
Differential Revision: https://phabricator.services.mozilla.com/D104547
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
This is slightly unfortunate on one hand because we're technically lying
(but so is chromium and our GTK theme, on the other hand).
It is nice because it means that themed and unthemed controls have the
same size by default though, which seems desirable.
So I'm a bit on the edge here, but I think this is probably the less bad
option to grow our form controls if we want to do it.
Differential Revision: https://phabricator.services.mozilla.com/D103477
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
If you add padding to the input on the inline-end, like some of the
examples in bug 1674431, then the darker border looks off.
Without it, the number input still looks nice, so I think we should do
this.
We might want to introduce the padding by default (see bug 1689286).
Differential Revision: https://phabricator.services.mozilla.com/D103270
We might want to snap focus outline widths as well, but that's harder
because it has various segments and separation between them, so we
probably want to snap those separately... So for now only border rects
probably makes sense.
Differential Revision: https://phabricator.services.mozilla.com/D103106
On Linux, the <scrollbar> minimum size must take into account the
minimum track size (which is larger than the general minimum widget
size).
On other platforms, the scrollbar buttons must also be taken into
account.
Differential Revision: https://phabricator.services.mozilla.com/D102885
Use the same width as the select arrow button makes sense to me and
fixes all the reported problems so far.
Also tweak the sizing / painting to take less height since these have a
background, so stuff like:
<input type=number style="height: 100px">
Looks super ugly otherwise.
The new polygon coordinates are the result of scaling by 1.5 and
centering vertically the arrow, which gives the same visual effect for
the regular input without margin / padding, but prevents the issue
described above with too-tall inputs or inputs with lots of padding.
We might want to shrink them a bit more if needed, but I think this is
alright. For reference, Chrome uses 15px, but we remove the inline-end
padding by default so we compensate a bit that way.
If we don't like how this looks when the author specifies padding on the
input (see comment 13 for example), we might want to reconsider the
design so that the spinners look good with padding, but that's a
different task completely.
Differential Revision: https://phabricator.services.mozilla.com/D102754
Outline should by default start outside of the border area, not inside.
Then we can use negative outline offsets to cover the border if we want
to.
This prevents the outline from getting inside the padding area.
Differential Revision: https://phabricator.services.mozilla.com/D102454
The only change I've made intentionally is the change to the textarea /
input padding. Now that the focus outline doesn't cover the padding
area, this preserves the same visual effect, plus the 2px inline padding
values now match Chrome, which means that even affecting appearance:
none controls, this is probably compatible.
Depends on D102458
Differential Revision: https://phabricator.services.mozilla.com/D102459
