1381938 - Switch to non-native theming of widgets for content on Windows, disabled by default behind widget.disable-native-theme-for-content pref

Status: RESOLVED FIXED

(Core :: Widget: Win32, enhancement, P1)

Description

[Alex Gaynor [:Alex_Gaynor]]

nsNativeThemeWin makes heavy use of the win32k APIs, so this is a blocker for the win32k lockdown effort.

https://docs.google.com/document/d/1d21-ff2mlNlNYX1CW0G9yRNNqSjMkjXRo9-MOXe1krs/edit?ts=596d1880#heading=h.xq1rtm3jj9o1 has a full set of stack traces, but a few example ones:

    win32u!NtUserGetWindowDC
    UxTheme!CImageFile::SelectCorrectImageFile+0x2cc
    UxTheme!CImageFile::GetScaledContentMargins+0x36
    UxTheme!CImageFile::GetBackgroundContentRect+0x36
    UxTheme!GetThemeBackgroundContentRect+0x127
    xul!nsNativeThemeWin::GetWidgetBorder+0x16b
    xul!nsBox::GetXULBorder+0x9d
    xul!nsIFrame::GetXULBorderAndPadding+0x22


    win32u!NtGdiDrawStream
    gdi32full!GdiDrawStream+0x5c
    UxTheme!CImageFile::DrawBackgroundDS+0x289
    UxTheme!CImageFile::DrawImageInfo+0x26c
    UxTheme!CImageFile::DrawBackground+0x66
    UxTheme!DrawThemeBackground+0x23c
    xul!nsNativeThemeWin::DrawWidgetBackground+0xb55
    xul!nsDisplayThemedBackground::PaintInternal+0xb0
    xul!nsDisplayThemedBackground::Paint+0x13

Comment 1

[Jim Mathies [:jimm]]

Attachment: wip

Comment 2

[Jim Mathies [:jimm]]

This is turning out to be a bit tricky, but not impossible on Windows. I'm unsure about GTK and OSX. 

First nsITheme supports a pretty short and well contained liost of apis. A few of these apis are easily remoted without much work. Then there is a subset that rely on various UX queues to make decisions, all of which rely on a presentation context object and an nsIFrame pointer for information. On Windows the use of these two pointers can be factored out.

The last api that presents a large hurdle is nsITheme's DrawThemeBackground. On Windows this api takes a gfxContext which wraps a DrawTarget and surface. This object gets handed to an old wrapper called gfxWindowsNativeDrawing which facilitates painting to the target, and in some cases facilitates alpha blending using alpha extraction.

Pretty sure we can create a fresh gfxContext + gfxWindowsNativeDrawing which interacts with a DrawTarget that is backed by a shared memory segment of some sort. Not sure if something like this exists though.. need to dig a bit more.

Not sure if I want to pursue this on all platforms.. we still have non-native theming in the works. TBD as I do more research.

Comment 4

[Jim Mathies [:jimm]]

Reopening this for win32 theming work.

Comment 5

[Mats Palmgren (inactive)]

So, uhm, is the intention here to stop supporting platform-themed form controls?
This seems like a rather fundamental change that should be discussed on dev.platform
but I can't find any posts about it there.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

(In reply to Mats Palmgren (:mats) from comment #5)
> So, uhm, is the intention here to stop supporting platform-themed form
> controls?
> This seems like a rather fundamental change that should be discussed on
> dev.platform
> but I can't find any posts about it there.

Native theming is already a mess on windows. Check out https://developer.microsoft.com/en-us/microsoft-edge/tools/screenshots/?url=http%3A%2F%2Fnativeformelements.com%2F?

We would still be using platformed-themed controls for Chrome.

What about this change worries you?

Comment 7

[Jim Mathies [:jimm]]

(In reply to Mats Palmgren (:mats) from comment #5)
> So, uhm, is the intention here to stop supporting platform-themed form
> controls?
> This seems like a rather fundamental change that should be discussed on
> dev.platform
> but I can't find any posts about it there.

We discussed this with Product but haven't posted on dev.plat. Our motivation here is security related: turning on os level security features on Windows which protects against kernel exploits. Due to this implementing these changes isn't really open for discussion.

That said understand your concern, I'll make sure the dev who works on this gives dev.platform a heads up seeking feedback.

Comment 8

[Mats Palmgren (inactive)]

> Native theming is already a mess on windows.

I don't see any "mess" there.  What are you referring to?

> We would still be using platformed-themed controls for Chrome.

Well, that's even worse.  Making buttons look different in "UI"
and web pages is... yikes.

> What about this change worries you?

See bug 1411425 comment 36, and dbaron's comments in bug 997190.

And even /if/ it can be implemented correctly, I consider platform-themed
form controls a feature, not a bug.  It certainly needs to be widely
discussed before a feature like this is removed.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

(In reply to Mats Palmgren (:mats) from comment #8)
> > Native theming is already a mess on windows.
> 
> I don't see any "mess" there.  What are you referring to?

All of the browsers draw platformed-themed controls differently. Even Microsoft is not consistent between Edge and IE 11.

As I understand it, we're the only browser on Windows 10 that's using the DrawThemeBackground API to draw our controls. I believe all of the other browsers just draw controls the same way as any other element. Continuing to use DrawThemeBackground as is, is not possible because it's not allowed when we remove win32k access from the content process.

If we did want to use DrawThemeBackground we'd need to come up with some kind of remoting strategy.

Do you have a suggestion for an alternative way to proceed here?

Comment 10

[Mats Palmgren (inactive)]

Fetching theme values from a remote process that has win32 access and
caching the values in the content process could work.

Alternatively, storing all the values we need upfront in the content
process and then dropping access to win32 APIs before any untrusted
content is processed might work - depending on what sandboxing
techniques you plan to use.  (like OpenBSD's "pledge" model)

Comment 11

[Alex Gaynor [:Alex_Gaynor]]

win32k dropping is enabled at process creation time, so it'd need to be fetched it a remote process and passed down, not at startup.

Comment 12

[Jeff Muizelaar [:jrmuizel]]

(In reply to Mats Palmgren (:mats) from comment #10)
> Fetching theme values from a remote process that has win32 access and
> caching the values in the content process could work.

There aren't theme values. The Windows API that we're using (DrawThemeBackground) is more like draw a widget of this type and this size to this DC. Using a sync IPC to do this would make our already bad widget drawing performance much worse.

Comment 13

[(No longer employed by Mozilla) Aaron Klotz]

I'm just spitballing here, but Android's NinePatch format comes to mind.
(For the unfamiliar, see https://developer.android.com/guide/topics/graphics/drawables#nine-patch)

My thought here is that in the chrome process we could use DrawThemeBackground to create and cache a bunch of small images that we then interpret as "NinePatch" images that can be stretched to fit the widgets as appropriate.

Comment 14

[(No longer employed by Mozilla) Aaron Klotz]

(Of course, I suppose the tricky part is figuring out which parts of the cached image are stretchable, but hopefully we could pull enough attributes via the Theming API that we could possibly compute that)

Comment 15

[Mats Palmgren (inactive)]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #12)

Well, I'm not an expert on Win32 so you shouldn't ask me for solutions.
I'm just saying that I find it questionable to remove features that
affect how web content looks without a wider discussion first.
(I still haven't seen any post to dev.platform, BTW.)

Comment 16

[Bob Owen (:bobowen)]

(In reply to Alex Gaynor [:Alex_Gaynor] from comment #11)
> win32k dropping is enabled at process creation time, so it'd need to be
> fetched it a remote process and passed down, not at startup.

I'm pretty sure it can be enabled after start-up.
Slightly irrelevant because as jrmuizel points out, without some caching plus sizing scheme we need to call the actual API.

I also think mats is right in that we should post to dev.platform about this.

Comment 17

[Stephen A Pohl [:spohl]]

Attachment: Bug 1381938 - Switch from native theming to CSS theming for widgets on Windows.

Comment 18

[Stephen A Pohl [:spohl]]

Attachment: Bug 1381938 - Switch from native theming to CSS theming for widgets on Windows.

Comment 19

[Stephen A Pohl [:spohl]]

Attachment: Bug 1381938: Add pref to disable native widget theming in content processes.

Comment 20

[Stephen A Pohl [:spohl]]

Attachment: Bug 1381938: Add CSS for widgets on Windows and stubs for Linux and macOS.

Depends on D24727

Comment 21

[Tim Nguyen :ntim]

I don't know how you plan to use content-common.css, but if this is going to be used in forms.css, it's going to create web compat issues, since we're changing the default UA styles of HTML elements. Also, using this in the Firefox UI will likely cause regressions to specificity issues (this is fixable, but the first issue isn't).

Can't we use Chrome's approach of defining their own "native" widget appearance on Windows? So instead of making -moz-appearance: button render the native Windows button appearance, it would paint an image that we would create ourselves as the background. This avoids the need of having to refactor CSS and having to deal with web compat problems.

Comment 22

[Tim Nguyen :ntim]

I don't know much about this code, but I guess that would mean rewriting widget/windows/nsNativeThemeWin.cpp to get rid of the native theme calls.

Comment 23

[Tim Nguyen :ntim]

Or if we still want to keep native theme calls for the parent process, we could have a brand new widget/nsBasicTheme.cpp and make nsPresContext::GetTheme() return the theme conditionally from widget/windows/nsNativeThemeWin.cpp or widget/nsBasicTheme.cpp.

Comment 24

[Stephen A Pohl [:spohl]]

(In reply to Tim Nguyen :ntim from comment #21)

I don't know how you plan to use content-common.css, but if this is going to be used in forms.css, it's going to create web compat issues, since we're changing the default UA styles of HTML elements. Also, using this in the Firefox UI will likely cause regressions to specificity issues (this is fixable, but the first issue isn't).

The current idea isn't so much to use content-common.css in forms.css, but rather in addition to forms.css, with the rules in content-common.css taking precedence over forms.css.

In terms of web compat, can you give specific examples?

content-common.css uses a lot of the same CSS that is used by the Firefox UI, but is not itself expected to be used by the Firefox UI. This may get refactored at some point and consolidated, but we are not trying to do this here.

Comment 25

[Tim Nguyen :ntim]

In terms of web compat, can you give specific examples?

Mats mentioned the concerns in comment 8, it doesn't sound like the scope of the current patch will let us avoid those.

If I understand correctly the current patches, basically every property that is set by content-common.css but not set by forms.css will basically cause compat issues: one example is the box-shadow/outline on focused inputs, buttons, which is something websites will now have to override with box-shadow: none if they define their own input border/background styles.

That's just one of many issues that could arise from changing the web content default UA CSS.

Since content-common.css would not be able to set more properties than forms.css, then it sort of makes content-common.css useless, since forms.css styles would take precedence over content-common.css all the time, meaning that just changing the different -moz-appearance values to none in forms.css would have the same effect as this patch.

I think a more safe approach here is to implement a new fake "native" theme for -moz-appearance: button, textfield, etc. that doesn't involve any platform API calls using C++, so the default UA styles don't need to change at all. That's basically what Blink is doing at the moment on Windows.

It would also give you more flexibility in regards of what default appearance you can apply, which is beneficial if you need to implement extra default styling for accessibility.

Comment 26

[Markus Stange [:mstange]]

(In reply to Tim Nguyen :ntim from comment #25)

I think a more safe approach here is to implement a new fake "native" theme for -moz-appearance: button, textfield, etc. that doesn't involve any platform API calls using C++, so the default UA styles don't need to change at all.

I agree, Tim's suggestion is the better approach.

Comment 27

[Markus Stange [:mstange]]

The corresponding Android bug for using C++ theming instead of CSS overrides is bug 958999.

Comment 28

[Stephen A Pohl [:spohl]]

(In reply to Markus Stange [:mstange] from comment #26)

(In reply to Tim Nguyen :ntim from comment #25)

I think a more safe approach here is to implement a new fake "native" theme for -moz-appearance: button, textfield, etc. that doesn't involve any platform API calls using C++, so the default UA styles don't need to change at all.

I agree, Tim's suggestion is the better approach.

To confirm my understanding: You both prefer an approach along the lines of what was mentioned in comment 13 and comment 14 due to the nature of the API as explained in comment 12, correct? The difficulty here has always been that the Windows API isn't just returning a set of values.

What if we only changed the properties that are currently set by forms.css? This would restyle the "Moz Unstyled Inputs" on the left side of http://stephenhorlander.com/form-controls.html. This wouldn't allow us to mirror the existing UX on our about: pages as we intended, but it may be an acceptable compromise. This would require some exploration to see how far we can take our styling and whether or not the result is acceptable.

Comment 29

[Tim Nguyen :ntim]

(In reply to Stephen A Pohl [:spohl] from comment #28)

(In reply to Markus Stange [:mstange] from comment #26)

(In reply to Tim Nguyen :ntim from comment #25)

I think a more safe approach here is to implement a new fake "native" theme for -moz-appearance: button, textfield, etc. that doesn't involve any platform API calls using C++, so the default UA styles don't need to change at all.

I agree, Tim's suggestion is the better approach.

To confirm my understanding: You both prefer an approach along the lines of what was mentioned in comment 13 and comment 14 due to the nature of the API as explained in comment 12, correct? The difficulty here has always been that the Windows API isn't just returning a set of values.

No, I was suggesting more simple than comment 13 and comment 14, we could create a basic C++ stub theme that doesn't look native at all. This is what Google Chrome is doing.

Comment 30

[Stephen A Pohl [:spohl]]

Attachment: Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange

Comment 31

[Stephen A Pohl [:spohl]]

Changing bug title to more accurately reflect the current approach.

Comment 32

[Asif Youssuff]

News on Microsoft's changes around this: https://blogs.windows.com/msedgedev/2019/10/15/form-controls-microsoft-edge-chromium/

Comment 33

[Stephen A Pohl [:spohl]]

Attachment: Bug 1381938: Add native theme for Windows that avoids native system calls. r=mstange

Comment 34

[Jeff Muizelaar [:jrmuizel]]

(In reply to Asif Youssuff from comment #32)

News on Microsoft's changes around this: https://blogs.windows.com/msedgedev/2019/10/15/form-controls-microsoft-edge-chromium/

Eg. https://chromium.googlesource.com/chromium/src/+/adc4f610d1e80b46f55e4a1ddabf06be1ace394c

Comment 35

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3e2d9328d59b
Add native theme for Windows that avoids native system calls. r=mstange,dbaron

Comment 36

[Bill Goldstein [:aja] (UTC-6)]

FYI, This probably blocks "Bug 1534333 - radio and checkbox need vector graphics" as well...which is likely a dup of 649948.

Comment 37

[Stephen A Pohl [:spohl]]

This is currently disabled by default behind the widget.disable-native-theme-for-content pref. I will be filing several followup bugs in the coming days, including a bug to turn this on by default.

Comment 38

[Bill Goldstein [:aja] (UTC-6)]

FWIW, if you're in the mood to innovate a bit, a unique appearance for indeterminate radios (disabled and not) would be a nice addition.
Currently, they can't be visually distinguished from unchecked radios...in Chromium, Edgium, current FF implementations, or with aforementioned pref set.

Comment 39

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/3e2d9328d59b

Comment 40

[Jim Mathies [:jimm]]

(In reply to Cristina Coroiu [:ccoroiu] from comment #39)

https://hg.mozilla.org/mozilla-central/rev/3e2d9328d59b

\o/ Woot!

Comment 41

[Chris Morgan]

Some feedback on the designs (not knowing a better place to put this at present), beyond things covered by bugs newly created:

• The increase from 13px to 17px for checkboxes and radio buttons while sticking with vertical-align: baseline harms the layout of the vast majority of uses of checkboxes. I’m immediately seeing all kinds of ugliness all over the place, in addon preference pages, in websites, everywhere that doesn’t basically replace checkboxes.

• That you can’t reduce the width of checkboxes and radio buttons below 17px can prevent sites from fixing that, too, and I suspect it may also harm some (though not most) “replace the checkbox widget” styles due to the control-made-invisible being larger than desired and unshrinkable.

• Making buttons largely indistinguishable from text boxes is extremely bad. (At a casual glance, until hover or focus, the difference is only the side padding of buttons.) They need to be styled visibly differently.

  • The buttons don’t look like buttons in any way. They should.

• <select> now lacks any visible focus indicator.

• In its hover behaviour, <select> is now styled more like a button than a textbox, which is contrary to how Windows has always (literally always; I can think of no counterexamples ever) treated them (though in line with most of macOS, where the distinction is fairly subtle, and in line with GTK, where the difference is huge and quite obnoxious).

• I believe the filled blue colouring for radio buttons and checkboxes is a mistake—it’s too opinionated, and clashes with existing site designs in a way that the old non-filled black style seldom did. (Related, blue border around a white centre feels not right for Windows, which has always had a border, then a white ring, then a filled centre; though it doesn’t feel as not-right as I thought it would.)

• Parts of the borders seem to be drawn outside the bounding box, which causes trouble with overflow, as seen at https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input. <input type=file> is a particularly severe example, being visually broken always unless you add padding: 1px or similar.

• Borders are also drawn on subpixels, which is undesirable.

• Unchecked checkbox and radio having a much thicker border than other controls feels weird, though I can understand why you’d do it. But for reference, Windows’ now-recommended styles use that sort of thicker border on all controls. But doing it everywhere would probably harm layout and appearance much more.

• I’m not sold on the border radius for checkboxes. It’s definitely not Windows’ way, and subjectively feels a tad more opinionated than not. I could say similar about text inputs (with which the checkbox radius is broadly consistent), but it doesn’t feel so significant for them, despite definitely not being the Windows way.

• The default invalid form field box-shadow clashes with the checkbox and radio button appearance.

• On <input type=range>, the hit boxes for the up/down arrows don’t extend to the right edge of the control, and they should.

For checkbox and radio button styles, I feel their appearance in about:preferences is closer to Windows’ conventions and a bit more neutral, though I’d still consider its blue a tad dubious for general use.

Comment 42

[Stephen A Pohl [:spohl]]

I'm going to n-i :shorlander for the feedback in comment 41. Note that there are some things (such as the lack of focus rings/indicators, bug 1615095) that are filed as follow up bugs that need to be addressed before we can turn this on by default.

Comment 43

[Chris Morgan]

A few more notes from a solid day of using it now:

• The indeterminate checkbox style is wonky—looks like it’s trying to draw a white dash, but didn’t replace the grey outline with the blue fill.

• I’ve encountered genuine layout and clipping problems in a few more places from the drastic increase in the size (particularly height, from padding) of buttons and text boxes. Things like a textbox now overflowing its containers vertically.

• The thicker borders on checkboxes and radio buttons are clashing visually all over the place—it’s normal for sites to style text boxes but not checkboxes and radio buttons, probably mostly because doing them is much more fiddly; so this matters. The more I use the web at large, the more I become convinced that 2px rather than 1px borders is a bad idea.

• Most web designs have more or less depended on the idea that checkboxes and radio buttons are 13px×13px. Increasing it to 17px×17px is regularly breaking layouts by a few pixels and leaving things surprisingly ugly, occasionally causing content clipping (e.g. the “enable flair on this subreddit” checkbox and label on https://old.reddit.com/r/rust if you’re logged in) and regularly leaving controls badly misaligned with text, especially in apps that have gone for smaller font-sizes (remember that 16px is the default for web content, but desktop apps have historically used decidedly smaller font sizes for their chrome, and mostly still do), which are also the things more likely to have lots of form controls.

• As an example of these last two points, the overly large checkboxes with their thick borders and rounded corners are comically out of place in Fastmail’s webmail in the list of emails, especially in the dark theme. (If it goes ahead as it is, it might be just enough for me to decide we should implement our own checkbox and radio button style on desktop. I don’t consider this a good thing.)

• Within the current macOS-like style, if the radio button is made huge, I expect the thickness of the blue border to scale with the radio button. Currently it stays the same thickness while the middle white grows, which makes it less obviously an oversized radio button.

• On the colour thing, I wonder whether there’s a way of letting the site specify colours to use, particularly for the primary blue. Simplest thing I can think of is defaulting to color: blue; (rather than color: inherit or similar), but that would be rather problematic. Not sure whether there’s active work in any standard that could sort this out. A custom property that the browser uses, a ::part(), I dunno.

Comment 44

[Sam Johnson]

I'd like to add to the feedback: When hovering a checkbox or radio button, the color appears to darken. Darker colors usually are used to show a pressed state, not a hover state, so this is a bit misleading to me. Generally, hover is indicated by a lighter color.

Comment 45

[Stephen A Pohl [:spohl]]

Filed several bugs to capture the feedback received so far (see individual bugs below). I've need-info'd :shorlander in the respective bugs, so removing it from this bug here:

(In reply to Chris Morgan from comment #41 and comment #43)

Some feedback on the designs (not knowing a better place to put this at present), beyond things covered by bugs newly created:

• The increase from 13px to 17px for checkboxes and radio buttons while sticking with vertical-align: baseline harms the layout of the vast majority of uses of checkboxes. I’m immediately seeing all kinds of ugliness all over the place, in addon preference pages, in websites, everywhere that doesn’t basically replace checkboxes.

• That you can’t reduce the width of checkboxes and radio buttons below 17px can prevent sites from fixing that, too, and I suspect it may also harm some (though not most) “replace the checkbox widget” styles due to the control-made-invisible being larger than desired and unshrinkable.

• I believe the filled blue colouring for radio buttons and checkboxes is a mistake—it’s too opinionated, and clashes with existing site designs in a way that the old non-filled black style seldom did. (Related, blue border around a white centre feels not right for Windows, which has always had a border, then a white ring, then a filled centre; though it doesn’t feel as not-right as I thought it would.)

• Unchecked checkbox and radio having a much thicker border than other controls feels weird, though I can understand why you’d do it. But for reference, Windows’ now-recommended styles use that sort of thicker border on all controls. But doing it everywhere would probably harm layout and appearance much more.

• I’m not sold on the border radius for checkboxes. It’s definitely not Windows’ way, and subjectively feels a tad more opinionated than not. I could say similar about text inputs (with which the checkbox radius is broadly consistent), but it doesn’t feel so significant for them, despite definitely not being the Windows way.

• The default invalid form field box-shadow clashes with the checkbox and radio button appearance.

For checkbox and radio button styles, I feel their appearance in about:preferences is closer to Windows’ conventions and a bit more neutral, though I’d still consider its blue a tad dubious for general use.

• The indeterminate checkbox style is wonky—looks like it’s trying to draw a white dash, but didn’t replace the grey outline with the blue fill.

• The thicker borders on checkboxes and radio buttons are clashing visually all over the place—it’s normal for sites to style text boxes but not checkboxes and radio buttons, probably mostly because doing them is much more fiddly; so this matters. The more I use the web at large, the more I become convinced that 2px rather than 1px borders is a bad idea.

• Most web designs have more or less depended on the idea that checkboxes and radio buttons are 13px×13px. Increasing it to 17px×17px is regularly breaking layouts by a few pixels and leaving things surprisingly ugly, occasionally causing content clipping (e.g. the “enable flair on this subreddit” checkbox and label on https://old.reddit.com/r/rust if you’re logged in) and regularly leaving controls badly misaligned with text, especially in apps that have gone for smaller font-sizes (remember that 16px is the default for web content, but desktop apps have historically used decidedly smaller font sizes for their chrome, and mostly still do), which are also the things more likely to have lots of form controls.

• As an example of these last two points, the overly large checkboxes with their thick borders and rounded corners are comically out of place in Fastmail’s webmail in the list of emails, especially in the dark theme. (If it goes ahead as it is, it might be just enough for me to decide we should implement our own checkbox and radio button style on desktop. I don’t consider this a good thing.)

• Within the current macOS-like style, if the radio button is made huge, I expect the thickness of the blue border to scale with the radio button. Currently it stays the same thickness while the middle white grows, which makes it less obviously an oversized radio button.

• On the colour thing, I wonder whether there’s a way of letting the site specify colours to use, particularly for the primary blue. Simplest thing I can think of is defaulting to color: blue; (rather than color: inherit or similar), but that would be rather problematic. Not sure whether there’s active work in any standard that could sort this out. A custom property that the browser uses, a ::part(), I dunno.

Bug 1617938

• Making buttons largely indistinguishable from text boxes is extremely bad. (At a casual glance, until hover or focus, the difference is only the side padding of buttons.) They need to be styled visibly differently.

• The buttons don’t look like buttons in any way. They should.

• I’ve encountered genuine layout and clipping problems in a few more places from the drastic increase in the size (particularly height, from padding) of buttons and text boxes. Things like a textbox now overflowing its containers vertically.

Bug 1617939

• <select> now lacks any visible focus indicator.

• In its hover behaviour, <select> is now styled more like a button than a textbox, which is contrary to how Windows has always (literally always; I can think of no counterexamples ever) treated them (though in line with most of macOS, where the distinction is fairly subtle, and in line with GTK, where the difference is huge and quite obnoxious).

Bug 1617940

• Parts of the borders seem to be drawn outside the bounding box, which causes trouble with overflow, as seen at https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input. <input type=file> is a particularly severe example, being visually broken always unless you add padding: 1px or similar.

• Borders are also drawn on subpixels, which is undesirable.

Bug 1615026

• On <input type=range>, the hit boxes for the up/down arrows don’t extend to the right edge of the control, and they should.

Bug 1615100

(In reply to Sam Johnson from comment #44)

I'd like to add to the feedback: When hovering a checkbox or radio button, the color appears to darken. Darker colors usually are used to show a pressed state, not a hover state, so this is a bit misleading to me. Generally, hover is indicated by a lighter color.

Bug 1617938

Comment 46

[Tom S [:evilpie]]

Should we maybe reshuffle some of these dependencies? Using a closed bug for tracking is a bit annoying.

Comment 47

[Stephen A Pohl [:spohl]]

(In reply to Tom Schuster [:evilpie] from comment #46)

Should we maybe reshuffle some of these dependencies? Using a closed bug for tracking is a bit annoying.

I agree.