1012818 - Consider moving focus to <input type=number> when a user clicks on one of its spin buttons

Status: UNCONFIRMED

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[mkoch42]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36

Steps to reproduce:

In the newest release, in a form that works in other browsers and used to work in FF, on the input type="number" field when onblur is fired we call a js function that records the id of the field for validation upon submission.   If we type in the field, the onblur fires. If we ONLY use the arrow to increment the number to 1, the onblur does not fire.


Actual results:

Onblur does not fire and our js functions do not get called if only the arrow is used on type="number" input fields to set the value of the field.


Expected results:

A user should click the arrow up to set the input type="number" field to 1, for example, and then when they click on the next form element, the js function that is called by onblur property should function.  This worked in previous releases and on all other current browsers.

Comment 1

[[ex-Mozilla] Agi Sferro | :agi]

Attachment: Give focus to number input control when changing value with the spinners

It looks like we don't give focus to the Input control when clicking on the spinners. If we want to do this, I think calling Focus() right after changing the value should work. 

I'm leaving the bug to UNCONFIRMED because I'm not sure if this is the behaviour we want.

Thanks!

Comment 2

[Jonathan Watt [:jwatt]]

(In reply to mkoch42 from comment #0)
> This worked in
> previous releases and on all other current browsers.

I don't think the behavior has chanced since <input type=number> was implemented in v29.

I also think this is the intended behavior, although I'm not sure who makes decisions about these things. There is definitely code that takes care _not_ to move focus under certain conditions when the user changes the value of form fields in a certain way, and I assume there was a reason for writing that code.

A better way to detect that validation is needed would be to listen for the 'change' event.

Comment 3

[Jonathan Watt [:jwatt]]

Stephen, do you know anything about the desired UX here, or who would?

Comment 4

[Jonathan Watt [:jwatt]]

Comment on attachment 8425214 [details] [diff] [review]
Give focus to number input control when changing value with the spinners

This wouldn't be the right place to make this change, but let's wait for UX input before spending time of figuring out where it would be.

Comment 5

[Stephen Horlander [:shorlander]]

(In reply to Jonathan Watt [:jwatt] from comment #3)
> Stephen, do you know anything about the desired UX here, or who would?

We don't seem to be consistent with our form element focus. I think it would make sense to for us to focus fields with type="number", with the text cursor placed after the number, if a user changes it with the spinner.

Comment 6

[Sander]

(In reply to Giovanni Sferro [:agi] from comment #1)
> Created attachment 8425214 [details] [diff] [review]
> Give focus to number input control when changing value with the spinners
> 
> It looks like we don't give focus to the Input control when clicking on the
> spinners. If we want to do this, I think calling Focus() right after
> changing the value should work. 
> 
> I'm leaving the bug to UNCONFIRMED because I'm not sure if this is the
> behaviour we want.
> 
> Thanks!

FWIW, in current Chrome/Opera versions, an <input type="number"> gets input if the up/down arrows (spinners) are used.

Related bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=1232233

Comment 7

[arni2033]

This bug must anyway be "NEW" because there's inconsistency: 
If I click <input type=number> spinner buttons with any modifiers (Ctrl / Alt / Shift), it becomes focused; 'focus' and 'blur' events fire several times. If input was already focused, then 'blur' fires 2 times, 'focus' - 2. If input wasn't focused, 'blur' fires 1 time, 'focus' - 2.

Comment 9

[C3po]

I just run into this issue: clicking on arrows does not fires the focus on the field. Did you take any decision about this UX point?

For those like who needs this to solved, here is a trick: http://jsfiddle.net/4ksywa6d/1/

Comment 10

[Francis]

This is quite an annoying issue, as DOM insertion includes changing the type. Our use case is for an INTL currency input:
- By default be input type="text" for INTL currency formatting,
- On focus/click change to input type="number" to benefit from browser number functionality.
- On blur change to input type="text" for INTL currency formatting again.

In Reactive UI programming this is much hit upon problem:
- https://github.com/facebook/react/issues/11062
- https://stackoverflow.com/questions/38770152/firefox-blurs-when-changing-the-input-type

And there appears to be multiple related issues on bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=981248
https://bugzilla.mozilla.org/show_bug.cgi?id=1057858

Comment 11

[Mirko Brodesser (:mbrodesser) -- not reading bugmails currently]

(In reply to Stephen Horlander [:shorlander] (If you're waiting on a response please ping me on Slack or IRC) from comment #5)

(In reply to Jonathan Watt [:jwatt] from comment #3)

Stephen, do you know anything about the desired UX here, or who would?

We don't seem to be consistent with our form element focus. I think it would
make sense to for us to focus fields with type="number", with the text
cursor placed after the number, if a user changes it with the spinner.

Assuming this is the UX decision, we should implement it.
A related issue: when resetting an unfocsed <input type="date"> element having a default value via clicking the reset button, the focus isn't moved to the input field. At least on Ubuntu 18.04. Chrome does move the focus.

Comment 12

[Alice0775 White]

I think this bug is also related to Bug 1542994

Comment 13

[Sander]

4.5 years since my previous comment, we're still running into this bug where I work. I managed to work around it by adding onclick="this.focus();" to the input.

Comment 14

[jryvola]

I'm having the same issue,
i.e.
'blur' does not fire on <input type="number"> after (1) clicking on the spinners and (2) moving away
FF 78.0.2 (64-bit)
Chrome and Edge do fire

Comment 15

[Dan]

Reported 7 years ago and nothing done?

There seems to be some debate about whether clicking the up/down arrows should focus the field.
Another way to think about it is when asking "Which field is in focus?".
If field A is in focus and I click up/down arrows on field B which is a number field, document.activeElement still reports that field A is in focus. This is clearly wrong.

Comment 16

[Matt Miller]

I just now worked around this in my code:

document.querySelector('#the_number_input').addEventListener('click', function () {
  if (document.activeElement !== this) {
    this.focus();
  }
});

It's a bit annoying to have to do this.