1882931 - Enable dom.forms.number.hide_spin_buttons_when_no_hover_or_focus in release?

Status: RESOLVED WONTFIX

(Core :: Layout: Form Controls, task)

Description

[Gregory Pappas [:gregp]]

In bug 1790700, a pref was added and enabled in Nightly which hides <input type=number> spin buttons when the input is not focused or being hovered. This matches the behavior of desktop Chromium. Do we want to ship this change to release?

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.
• This change makes it harder to know at a glance if an input is type=number, because it will just look like a text input until you hover/click it.
  Is this a big issue? I'm not sure.

Comment 1

[Daniel Holbert [:dholbert]]

Looks like the pref was only added 5 days ago (by you I see -- thanks!). It might be worth giving it a release cycle before riding the trains, to see if any issues crop up.

FWIW, just as another data-point: desktop Safari seems to show the spin-buttons unconditionally (matching pre-bug 1790700 behavior). For the sites you mentioned that expect the spin-buttons to hide, I guess they look bad in Safari too? Also: I don't have iOS Safari handy to test, but it'd be interesting to see what they do as well.

It may be worth trying to getting UX input, per bug 1790700 comment 2, but maybe this is a small enough change to be fine with an engineering r+, if no regressions crop up.

Comment 2

[Gregory Pappas [:gregp]]

Hello Jules, are you the right person to ask for UX feedback? I can't find any documentation for a formal UX feedback process...so here's a semi-random needinfo 🙂

Comment 3

[Jules Simplicio [:jules]]

Hey Gregory and Daniel, it'd be nice to think through UX considerations such as the one Gregory mentioned that this may end up looking like a text input and that it could potentially be a usability issue. We also tend to avoid showing controls on hover only due to accessibility, so I'd probably check in with those folks too.

The design systems team I'm in would be able to help with this type of UI work. When are you hoping to get some feedback by? I can add this to my team's tasks for providing support. In general, you can request UX design help here https://mozilla-hub.atlassian.net/jira/secure/CreateIssue.jspa?pid=10357&issuetype=10059 and for anything that feels user interface design systems related, feel free to reach out in Slack at #acorn-design-system. You can always ni? me on bugs if you need help.

Comment 4

[Gregory Pappas [:gregp]]

When are you hoping to get some feedback by?

Probably June 6th, which is when the soft code freeze for the next ESR (128) starts. This isn't really time sensitive, but If the feedback is negative, I'd personally prefer to have the pref removed before the next ESR is released.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 1, for convenience to visualize the behavior

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Jules Simplicio [:jules] from comment #3)

In general, you can request UX design help here https://mozilla-hub.atlassian.net/jira/secure/CreateIssue.jspa?pid=10357&issuetype=10059

That has a bit more overhead than the request here; I typed up a draft request there (filling out "summary" and "description"), but the form wants me also to provide values for:
Please fill out Feature field.
Please fill out the Project name field.
Please fill out the OKR field.
Please fill out the Project Manager field.
Please fill out the Link to PRD field.
Please fill out the Deadline field.

and for anything that feels user interface design systems related, feel free to reach out in Slack at #acorn-design-system. You can always ni? me on bugs if you need help.

I'll try to do that tomorrow. Note that this is sort of an aesthetic choice, not super high-stakes.

(Note that the original issue on bug 1790700 had a webcompat issue associated with it, but that issue is no longer a problem because we hide these up/downarrows entirely on Android now, independent from the Desktop-specific pref being discussed here.)

Comment 7

[Daniel Holbert [:dholbert]]

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

Comment 8

[Gregory Pappas [:gregp]]

I agree with Daniel. Another thing to keep in mind is that a page can hide the spin buttons by setting the value of the appearance css property to textfield.

Comment 9

[Daniel Holbert [:dholbert]]

After some discussion with UX and a11y folks (particularly jules, ayeddi, jteh - thanks everyone!), we've decided it's probably best to keep our existing behavior (i.e. not enable the pref, which means we should probably just remove it).

High-level reasoning:

• The buttons are a useful visual clue that this is a number input field.
• Hiding them doesn't get us any sort of freeing-up-space benefit, as discussed in comment 7 part (b).
• If web developers have aesthetic reasons to hide them, they can do so (per comment 8)
• There's a slight argument that autohiding them on desktop would improve visual consistency with mobile (since they're always hidden on Android now, per comment 7 part (a)). But that's not a strong argument because form controls interaction on mobile vs. desktop is quite different in general anyway (e.g. popups for select-menu and input type=file, auto-zoom-on-focus, special keyboards based on field type). And these arrow-buttons are typically too small to be useful tap targets on mobile in most cases, so it makes a fair amount of sense that they're missing there vs. present on desktop.

And there are various reasons that it's better for a11y to have them consistently present (not hiding/showing based on hover state):

• If we hide the buttons until hovered/focused, speech recognition users would not be able to directly activate them via the mouse grid (using assistive tools where you can instruct your computer to tap a particular geometric area of the screen, basically; see e.g. t=1:40 in https://www.youtube.com/watch?v=yGOP2fOp7TA )
• Similarly: users who are using a screen-magnifier tool might be hovering/looking near an input element but not explicitly hovering it, and might not realize that these buttons are available.
• Unnecessary sudden visual changes (e.g. buttons appearing/disappearing on hover) can cause some users to lose concentration or get confused about what caused the UI to change.

I'm not sure what Chrome's reasoning is for dynamically hiding them, but the webcompat win of aesthetically matching Chrome on this point doesn't seem to be worth these^ drawbacks.

Comment 10

[Daniel Holbert [:dholbert]]

gregp: thanks for adding this experimental configuration as part of bug 1790700, in any case! Based on comment 8 I suspect you're not too invested in keeping it, though feel free to post if there's anything important that we might be missing here.

Or, if we're all on the same page, perhaps you'd like to do the honors of removing the pref?

Comment 11

[Gregory Pappas [:gregp]]

Thanks for the detailed summaries and test cases, Daniel!

Based on comment 8 I suspect you're not too invested in keeping it

Yeah, I was neutral towards this concept in the beginning but grew to dislike it after using it for a while.

perhaps you'd like to do the honors of removing the pref?

Happily!

Resolving this bug as WONTFIX; will do the removal in a new bug rather than repurposing this one.

Comment 12

[Daniel Holbert [:dholbert]]

For the record, the new bug (where we removed this pref) was bug 1899401.