This can occur once all major bugs have been addressed that block bug 1381938.

A few more remarks (previous remarks of mine have been on bug 1381938) that for me as an outsider to the project don’t fit neatly into “file a new bug about it, please”. Do what you will with them.

Concerning the increased sizes and padding:

• This is a minor problem on a great many websites.
• It makes things imperfect on literally most websites that have checkboxes and radio buttons. Admittedly in many of these cases the designs are already imperfect, but also in many they are not.
• I’m fairly regularly coming across sites that are seriously mangled by the changes. e.g. today I accessed a TP-LINK router which has the CSS select { height: 22px; box-sizing: border-box }, and the effect is that vertically I see 1px of border, 6px of padding (!), 8px of content, 6px of padding, 1px of border. In practice that 8px of content reveals only the top 4px of capital letters, and 1px of lowercase letters. Before, I believe the entire text was visible (I’m too lazy to flip the switches and check), and it certainly is in other browsers. Buttons get similar treatment in the CSS, but the text is allowed to overflow over roughly five of the six pixels of padding-bottom, so that only a small part of the label text is clipped. But that’s still very ugly.

This use of padding on buttons and dropdowns is very problematic. Even if you keep the same dimensions of the field (which I think is a mistake), the padding needs to be sacrificed if the height is constrained. I can’t think of a good way of achieving that within the scope of how I imagine it being implemented; hopefully developers can.

Other remarks:

• Selects are currently a bizarre hybrid text box/button in style, taking most of the worst parts of the style of buttons, and applying them to a text box. This is varying degrees of wrong, by platform, feeling very wrong on Windows.
• Currently on some pages on news.ycombinator.com, I’m not seeing the resize grippy on textareas, though the functionality is still there in the corner; this persists even if I reduce the page down to just the textarea, with no styles or anything, and across page reloads; but not, apparently, on new tabs, or if I duplicate the markup elsewhere. I’m rather baffled what’s going on here. Just thought I’d mention it in case it suggested anything to anyone.
• The button style is still a very serious regression in its affordances. Please don’t ship it as it is.
• Changing just border-color doesn’t behave as I expect on some controls (e.g. on textarea it’s too thick and should perhaps be solid rather than inset).
• Scrollbar rendering on textareas is wonky in its interactions with the border and rounded corners; this could perhaps be addressed as part of bug 1619425 or bug 1615038, but it may warrant a separate issue to make sure it’s tracked.

Some of my previous remarks are still applicable (some with bugs created for them, some not), but some have also been fixed—thanks for that.

(In reply to Chris Morgan from comment #1)

A few more remarks (previous remarks of mine have been on bug 1381938) that for me as an outsider to the project don’t fit neatly into “file a new bug about it, please”. Do what you will with them.

Thank you for your comments. Unfortunately, since this is an effort across multiple teams with various folks involved, we need to file dedicated bugs for this kind of feedback to get better traction behind the various issues. I know this is a lengthy process, but if you could go over your feedback and either add it to some of the bugs that I filed for you, or file new ones, that would be greatly appreciated. If you do not have the time, I will do so myself eventually, hopefully early next week.

Some of my previous remarks are still applicable (some with bugs created for them, some not), but some have also been fixed—thanks for that.

I'm hopeful that all of your previous feedback was captured in the various bugs I filed. If there is anything missing, please let me know (or feel free to file new bugs accordingly).

Tracking non-native theming bugs for Fission Beta milestone (M7).

Shipping NNT on Windows is not a Fission blocker.

Not a Fission bug

Hi Emilio,

1. Can we close this Windows meta bug as fixed by "Let non-native theme ride to Beta and Release" bug 1697053?

2. This meta bug has one open blocking it: bug 1695553 about Windows 7 scrollbars. We've already enabled non-native theme on Windows 7. Do we still need to fix Windows 7 scrollbars? Or can we resolve bug 1695553 as WONTFIX or WORKSFORME?

(In reply to Chris Peterson [:cpeterson] from comment #6)

1. Can we close this Windows meta bug as fixed by "Let non-native theme ride to Beta and Release" bug 1697053?

Yes

2. This meta bug has one open blocking it: bug 1695553 about Windows 7 scrollbars. We've already enabled non-native theme on Windows 7. Do we still need to fix Windows 7 scrollbars? Or can we resolve bug 1695553 as WONTFIX or WORKSFORME?

Unclear. Should we check with UX? I can work on it if needed.

Let's close this as a dupe of bug 1697053. I can check win 7 scrollbars tomorrow.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)

(In reply to Chris Peterson [:cpeterson] from comment #6)

2. This meta bug has one open blocking it: bug 1695553 about Windows 7 scrollbars. We've already enabled non-native theme on Windows 7. Do we still need to fix Windows 7 scrollbars? Or can we resolve bug 1695553 as WONTFIX or WORKSFORME?

Unclear. Should we check with UX? I can work on it if needed.

I'm clearing this needinfo request since we're already discussing Windows 7 scrollbars in email. My recommendation is that we just ship what we have now (Windows 10 style scrollbars) to Windows 7 users.