Open Bug 1012818 Opened 7 years ago Updated 7 months ago

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

Categories

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

defect

Tracking

()

UNCONFIRMED

People

(Reporter: mkoch42, Unassigned)

References

Details

Attachments

(1 file)

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.
Blocks: 344616
Component: Untriaged → DOM: Events
Product: Firefox → Core
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!
Attachment #8425214 - Flags: review?(jwatt)
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 32 Branch → Trunk
(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.
Stephen, do you know anything about the desired UX here, or who would?
Flags: needinfo?(shorlander)
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.
Attachment #8425214 - Flags: review?(jwatt) → review-
(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.
Flags: needinfo?(shorlander)
Summary: Onblur event not fired when using arrows on type="number" input field → Consider moving focus to <input type=number> when a user clicks on one of its spin buttons
(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
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.
See Also: → 1208928
Duplicate of this bug: 1232233
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/
See Also: → 1057858
Priority: -- → P5
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

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

I think this bug is also related to Bug 1542994

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.

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

Component: DOM: Events → DOM: UI Events & Focus Handling
You need to log in before you can comment on or make changes to this bug.