rugk Reporter
	Description • 6 years ago

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180530201455

Steps to reproduce:

Follow https://developer.mozilla.org/en-US/Add-ons/WebExtensions/user_interface/Browser_styles and add the "browser-style" class to my input parent elements.


Actual results:

It works, but the <input c type="radio"[…]> elements get no special style. (at least not on GNOME here)

They look like usual buttons.


Expected results:

For testing, I copied and applied the same CSS that the <button elements get via browser-style – because the color input also looks like a button – and it looks quite decent, so maybe this is an idea:. (see attachment)

	Adrian Florinescu [:aflorinescu]
	Comment 1 • 6 years ago

Thanks for the issue. Could you add a reduced testcase as an example to reproduce the issue?

	Adrian Florinescu [:aflorinescu]
	Comment 2 • 6 years ago

Please reopen after reviewing comment 1.

	rugk Reporter
	Comment 3 • 6 years ago

This is a feature rather a feature request, not a bug. It's just that you have no style here.

But if you want, here is a "testcase" with a modified version of the "forget-it" webextension examples:

	rugk Reporter
	Comment 4 • 6 years ago

The settings page shows one button, which has a browser-style. The input=color, however, does not have a browser-style. Doc: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/user_interface/Browser_styles

	Adrian Florinescu [:aflorinescu]
	Comment 5 • 6 years ago

Thanks for the additional details. 
I've looked at the test case in Chrome and Firefox 63.0a1 07-19-2018 on Ubuntu 16.04, but IMO I'd expect the input element to look like that. I'm going to mark this bug as new and move this to a more suitable component for further review and triage.

	rugk Reporter
	Comment 6 • 6 years ago

Do compare it with the style of a button with "browser-style". Adding "browser-style" to input type="color" just **does not change the style**. This is not at all expected and when all your UI uses the browser-style deisgn, it is really visible that this does not change it's design.

Again, this is obviously a missing style, it's just not implemented.

	Daniel Holbert [:dholbert]
	Comment 7 • 6 years ago

Thanks for the report.

It looks like the issue here is basically that the CSS file "chrome://browser/content/extension.css"[1] (referenced in the MDN page from comment 0) -- and the problem is that it provides a bunch of custom styling for <button> elements with the "browser-style" class, but it doesn't have any matching styles for <input> elements that render as buttons. (input type=color|submit|button|reset)

I don't know anything about this extension.css file, but to the extent that we care about it providing consistent look across form widgets, it does indeed seem like we should broaden/generify its "button" styling to apply to these input[type="..."] selectors as well.

For reference/comparison, here[2] is the file where we do that for default styling of buttons on web pages in general, which has a lot of selectors that look like:
> button,
> input[type="color"],
> input[type="reset"],
> input[type="button"],
> input[type="submit"] {

[1] https://searchfox.org/mozilla-central/rev/246f2b4fab2c1a6cca99418bc2e4d73d1102cc38/browser/components/extensions/extension.css
[2] https://dxr.mozilla.org/mozilla-central/rev/4e56a2f51ad739ca52046723448f3129a58f1666/layout/style/res/forms.css#601

	Daniel Holbert [:dholbert]
	Comment 8 • 6 years ago

bwinton, looks like you've got some history with this extension.css file - maybe you could take a look here, or know who could?

	Blake Winton (:bwinton) (:☕️)
	Comment 9 • 6 years ago

I don't think we took those into account when designing the stylesheet, so feel free to update it to cover those cases, too. :)

	rugk Reporter
	Comment 10 • 6 years ago

BTW also input=range is not supported/displayed in any different way. Should I open a new issue for that or is it okay to collect it here?

	rugk Reporter
	Comment 11 • 6 years ago

*input type=range, of course

	Daniel Holbert [:dholbert]
	Comment 12 • 6 years ago

rugk: yes, <input type="range"> issues should be filed separately, as that widget doesn't typically render like a button (and this bug here is about consistency between button-flavored input types).

If you happen to be on Ubuntu 18.10 (or using Ubuntu's "Yaru" theme on a different linux version), your issue might already be tracked in bug 1501858.

	rugk Reporter
	Comment 13 • 6 years ago

Okay, opened bug 1504945 for that.