(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.)
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: 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.)