Open Bug 1012818 Opened 10 years ago Updated 1 year ago
Consider moving focus to <input type=number> when a user clicks on one of its spin buttons
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.
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?
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.
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
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/
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
You need to log in before you can comment on or make changes to this bug.