This is a followup on https://webcompat.com/issues/4177 input[type="checkbox"] { background: 0; -moz-appearance: none; } blocks the check-mark on <input type="checkbox" checked/> on Gecko while it appears on Blink and WebKit Probably a regression. Eric Tsai found the range for the regression > Use mozregression, looks like the bug is caused by changeset in 2016-11-21 > Last good revision: 0534254e9a40b4bade2577c631fe4cfa0b5db41d (2016-11-22) > First bad revision: 0ddfec7126ec503b54df9c4b7c3b988906f6c882 (2016-11-23) Here a test illustrating the issue. http://codepen.io/webcompat/pen/EZxLdL and its rendering in attachment (left to right Gecko, WebKit, Blink)

Maybe I have been too quick. I had forgotten to add -webkit-appearance: none; on the test.

Ok the initial page has no -webkit-appearance: none so their intent is really to show the widget. but somehow it blocks the click with background: 0;

(In reply to Karl Dubost :karlcow from comment #0) > Eric Tsai found the range for the regression > > Use mozregression, looks like the bug is caused by changeset in 2016-11-21 > > Last good revision: 0534254e9a40b4bade2577c631fe4cfa0b5db41d (2016-11-22) > > First bad revision: 0ddfec7126ec503b54df9c4b7c3b988906f6c882 (2016-11-23) https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0534254e9a40b4bade2577c631fe4cfa0b5db41d&tochange=0ddfec7126ec503b54df9c4b7c3b988906f6c882 Bug 418833 is in that, which is a likely cause.

Bug 418833 made us use background images to draw the checkmark, so if a page overrides that we won't draw anything.

(In reply to Timothy Nikkel (:tnikkel) from comment #4) > Bug 418833 made us use background images to draw the checkmark, so if a page > overrides that we won't draw anything. That's correct. We use a background image for the checkmark. What's the right behaviour here? Setting -*-appearance none seems to remove all visible styles from the element for both Blink and WebKit, including the checked state.

Hi Mike (Conley) yup. Hard to crack. I propose to put that on hold. I will try to contact them (on webcompat.com) and also try to find out if this change is breaking things elsewhere. I'll ni you if I find something.

-webkit-appearance: none makes blink/webkit draw nothing at all. -moz-appearence: none makes gecko draw non-native themed checkbox. So the website was probably expecting the old gecko behaviour. So we can either be compatible with ourselves, or webkit/blink, but not both :(

Thanks Timothy. I initiated contacts with mercadolibre

(In reply to Timothy Nikkel (:tnikkel) from comment #7) > -webkit-appearance: none makes blink/webkit draw nothing at all. > -moz-appearence: none makes gecko draw non-native themed checkbox. -moz-appearance:none on checkbox/radio controls should now (v54) be compatible with Chrome and Edge (fixed in bug 605985, bug 1338293, bug 1322698). Note also that bug 1333482 will land soon, removing -moz-appearance and adding support for appearance/-webkit-appearance instead.

So is there anything to fix in Gecko in this bug? (I don't think setting 'background' on a checkbox/radio control has any effect in any browser unless you also set *appearance:none.)

Mats, sniff sniff… we are doomed. Cf https://groups.google.com/forum/#!msg/mozilla.dev.platform/oZ9cPF8Y1pE/LiSUtpeHBwAJ so if we remove `-moz-appearance: none`, * we fix this Web site! YEAH! (I don't know other sites depending on this behavior) * we break Japan Airlines site. RHA! I would suggest, we leave it as-is for now until we have solved the -moz-appearance issues for none and button.

Mike, Karl, can you please test Nightly on the sites that reported issues here? Both Firefox/Fennec if you can. I'd like to know what effect bug 605985 + bug 1333482 has on these sites. Note that all three of -moz-appearance/appearance/-webkit-appearance are now enabled in Nightly (and soon Aurora). The latter two only recognize 'none' though, not other values. -moz-appearance has unchanged semantics, although it is now trumped by a (-webkit-)appearance:none. Thanks!

:mats, Firefox 55 (2017-03-29) on Linux doesn't fix https://webcompat.com/issues/4177 for me. Also Firefox mobile 55.0a1 (2017-03-29 on Z3C doesn't fix https://github.com/webcompat/web-bugs/issues/4654 for me. I can't see the checkbox works as expected today.

Using Firefox Nightly 55.0a1 (2017-03-29) (64-bit) ========================================================== # https://webcompat.com/issues/4177 (reported for desktop) http://lista.mercadolivre.com.br/audio-profissional-microfones/dinamicos/_Frete_Gratis_OrderId_PRICE_ItemTypeID_N_OtherFilterID_MEJVEN .nav-search .nav-category input[type="checkbox"] { border: 1px solid #ccc; background: 0; -webkit-box-shadow: none; box-shadow: none; display: inline-block; margin: 3px 5px 0 0; height: 14px; padding: 0; vertical-align: top; width: 14px; -moz-appearance: none; -webkit-border-radius: 3px; border-radius: 3px; } Desktop: Checkbox still not working. Mobile: No checkbox. different design. ========================================================== # https://webcompat.com/issues/4654 (reported for mobile) https://ca.godaddy.com/news/unsubscribe.aspx?email=foo@bar.com button, input, select[multiple], textarea { background-image: none; } Desktop: working Mobile: not working ========================================================== # https://webcompat.com/issues/4837 (reported for mobile) https://www.metro.ca/concours/evenement-millionnaire Not possible to test anymore the contest has been closed. But according to the initial bug report. The CSS was: button, input, select[multiple], textarea { background-image: none; } And desktop was working at the time, but not mobile. And given this is the exact same rule than the previous issue, it probably comes from a framework or an article. ========================================================== Checking a bit more and I see in the BootStrap project https://github.com/twbs/bootstrap/blob/296c99020c0f7c8122b8cd1a7f93c0797f8ff8dd/scss/_forms.scss#L17-L18 https://github.com/necolas/normalize.css/issues/214 which links to Bug 900871 which was closed as a DUP of Bug 763671 They point to https://hg.mozilla.org/mozilla-central/file/d2ce76654a6a/mobile/android/themes/core/content.css#l120 as the source of their issue. background: white linear-gradient(rgba(115,115,115,0.5) 0, rgba(215,215,215,0.5) 3px, rgba(255,255,255,0.2) 16px); In this issue there are a couple of repeat. It was finally handled here https://github.com/twbs/bootstrap/pull/9567/files to close https://github.com/twbs/bootstrap/issues/8702

(In reply to Karl Dubost :karlcow from comment #14) > # https://webcompat.com/issues/4177 (reported for desktop) > > http://lista.mercadolivre.com.br/audio-profissional-microfones/dinamicos/ > _Frete_Gratis_OrderId_PRICE_ItemTypeID_N_OtherFilterID_MEJVEN > > .nav-search .nav-category input[type="checkbox"] { > border: 1px solid #ccc; > background: 0; > -webkit-box-shadow: none; > box-shadow: none; > display: inline-block; > margin: 3px 5px 0 0; > height: 14px; > padding: 0; > vertical-align: top; > width: 14px; > -moz-appearance: none; > -webkit-border-radius: 3px; > border-radius: 3px; > } > > Desktop: Checkbox still not working. > Mobile: No checkbox. different design. Thanks Karl. So, the regression in v53 for this rule is that we switched from painting check marks in C++ to using UA sheet background images in bug 418833. The 'background: 0' above trumps those UA background styles. In v54/55 we made those UA styles Android-only, which makes no difference for the above rule, on any platform, so the check marks are still not painted. Bug 605985 explicitly excluded Android, and bug 1333482 doesn't affect the above rule since it doesn't use appearance/-webkit-appearance. The only options to make the above rule work is to either: 1. revert everything back to v52 -or- 2. ship all changes we have in v55 + disable '-moz-appearance', and that would still only fix desktop, not mobile. To fix mobile we need to additionally implement a native theme for radio/checkbox on Android. Note: 2. is the long term solution we're aiming for (in v54 hopefully). The other sites works on desktop because setting background properties doesn't affect controls with a native theme. They don't work on mobile because their 'background' styles wins over our UA styles. I suspect they are all a regression from bug 418833. I don't think it's realistic to implement option 2 for v53, so the only option is to backout bug 418833 from v53, or accept these regressions. IMO, the latter is unacceptable if this affects more than a few sites. Now, to come back to the "+ disable '-moz-appearance'" bit. That was what my original patches in bug 1333482 did, but there was some concern that disabling it would not be web compatible so we decided to disable it in a future release instead and ship all three properties enabled. However, the above rule is a clear indication that keeping it enabled also has some web compat risk. So, I'm now a bit worried about how common it is that authors specify '-moz-appearance:none' but not '-webkit-appearance:none'. So I would appreciate more Nightly testing on other sites that are using form controls. I would also appreciate testing real sites with Nightly desktop builds with -moz-appearance disabled (layout.css.moz-appearance.enabled). (You only need to reload the page, no restart required.) It would also be good to do the same test with a fake the UA string to convince the site that you're using Fennec, in case they have different styles for mobile. (This will tell us if a future Fennec with native theme in option 2 will work.)

Thanks for testing Eric and Karl. I'll send an email to the compat list with mats' ask from Comment #15 so we can all be aware.

You might want to look at this one. https://webcompat.com/issues/5511 The site works in Firefox 52.0 but not in Firefox 55. with .reboot input[type="checkbox"] { background: 0 0; }

https://webcompat.com/issues/5571 has similar case as https://webcompat.com/issues/5511 works in Firefox mobile 52 but fails in 55.

Karl, Eric, both those sites works fine in Nightly on Linux so I'm pretty sure they will work also on mobile once we do the backout we did for v53 (bug 1352406) also for v55/v54. That will happen as part of bug 1352238.

[Tracking Requested - why for this release]: Web compat regression.

Tracking 54/55+ per Comment 20.

Hi Karl & Eric, We've backout v54/v55 through bug 1357169. Does that help?

I think it should help, but not see on Fennec 2017-05-11. Will wait and test when it's merged. Any plan date?

Hi Eric, The codes have been backed out a couple of weeks ago. It should take effect.

We just have to wait for the native theme on Android. Bug 1352238

Per comment #25, this needs a lot of dev work and it's late beta now. Mark 54 won't fix.

Untracked for 55 as I don't think bug 1352238 (tracked for 56+) will get fixed by August 8th.