Bug 1882931 Comment 7 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Gregory Pappas [:gregp] from comment #0)
> A few considerations (non-exhaustive):
> - This is a mild web compatibility improvement. Some websites are designed with the assumption that spin buttons will not be visible when the <input> isn't focused or hovered, these pages will look a bit nicer in Firefox.

Followup note on this purported web compatibility impact here: tl;dr I'm not sure there's really much of a webcompat benefit.  The original webcompat issue that inspired this change, in bug 1790700, was about a problem where these buttons were **covering up the number-field's contents on Android** when the numerals don't all fit.  That issue and issues like it aren't relevant to the consideration here, though, because:
(a) ...on Android: we now hide these arrows *entirely* (gregp unconditionally hid these buttons on Android  as part of the same patch in bug 1790700, to match Chrome-on-Android)
(b) ...on Desktop: the button-box still steals space from the area-where-numerals-can-paint, in Firefox as well as in Chrome, regardless of this pref (even for unfocused fields where the buttons aren't painting).  So the autohiding behavior doesn't buy us any extra real-estate for numerals there.

So in terms of pros/cons here:  as I see it, the main improvement that we could claim from enabling this pref is just cosmetic; it reduces the amount of mandatory browser-imposed UI that we draw over a web page that's outside of the web developer's control, which means we're less likely to be accidentally clashing with a website's theme.  If a particular website is designed such that buttons-with-a-gray-background look out-of-place, then it's perhaps nicer for us to avoid drawing these gray spin-buttons all over the place.

(I'm not particularly tied to either behavior, though; just trying to flesh out possible reasons to favor one design over the other.)
(In reply to Gregory Pappas [:gregp] from comment #0)
> A few considerations (non-exhaustive):
> - This is a mild web compatibility improvement. Some websites are designed with the assumption that spin buttons will not be visible when the <input> isn't focused or hovered, these pages will look a bit nicer in Firefox.

Followup note on this purported web compatibility impact here: the new behavior does align with Chrome-on-Desktop, but I'm not sure there's really much of a webcompat benefit, functionality-wise at least.  The original webcompat issue that inspired this change, in bug 1790700, was about a problem where these buttons were **covering up the number-field's contents on Android** when the numerals don't all fit.  That issue and issues like it aren't relevant to the consideration here, though, because:
(a) ...on Android: we now hide these arrows *entirely* (gregp unconditionally hid these buttons on Android  as part of the same patch in bug 1790700, to match Chrome-on-Android)
(b) ...on Desktop: the button-box still steals space from the area-where-numerals-can-paint, in Firefox as well as in Chrome, regardless of this pref (even for unfocused fields where the buttons aren't painting).  So the autohiding behavior doesn't buy us any extra real-estate for numerals there.

So in terms of pros/cons here:  as I see it, the main improvement that we could claim from enabling this pref is just cosmetic; it reduces the amount of mandatory browser-imposed UI that we draw over a web page that's outside of the web developer's control, which means we're less likely to be accidentally clashing with a website's theme.  If a particular website is designed such that buttons-with-a-gray-background look out-of-place, then it's perhaps nicer for us to avoid drawing these gray spin-buttons all over the place.

(I'm not particularly tied to either behavior, though; just trying to flesh out possible reasons to favor one design over the other.)

Back to Bug 1882931 Comment 7