<input type=number> should not fire extra focus/blur events when script focuses it immediately after inserting it into the document or making it visible by removing display:none
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
People
(Reporter: obrufau, Assigned: mbrodesser-Igalia)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:34.0) Gecko/20100101 Firefox/34.0 (Beta/Release) Build ID: 20140824030210 Steps to reproduce: Create a <input type="number">, append it to the DOM, and .focus() it. Actual results: Before receiving the focus event, it receives a blur event. Expected results: The spec (http://www.w3.org/TR/html5/editing.html#dom-focus) doesn't say anything about firing a blur event, and Chrome doesn't do it. Note it works well with other input types. It also works if .focus() is called some time after appending to the DOM (e.g. setTimeout).
Comment 1•9 years ago
|
||
I've just experienced another (possibly related?) issue with focus on a number. checking the offsetWidth of an unrelated element seems to trigger focus events on the focused <input type=number> (causing infinite recursion in this case)
Comment 2•9 years ago
|
||
Does reproduce in Firefox 37.0.2 on the following fiddle: http://jsfiddle.net/tn71zboe/1/ Calling `focus()` synchronously right after insertion into DOM results in three events: blur, focus, focus. Target fields of all three events point to the same input. Calling `focus()` asynchronously increases probability of expected event (just single focus, without additional blur/focus pair). Approximately at 100ms timeout Firefox works as other browsers (i.e. fires single focus event).
Comment 3•9 years ago
|
||
I have an issue that might be related. I have a focused field of a given type. When changing its type to "number", a `blur` and another `focus` event are immediately triggered. Here's a fiddle: https://jsfiddle.net/5gc7upLj/ This could be a separate bug, but it only seems to happen with type="x" to type="number".
![]() |
||
Comment 4•8 years ago
|
||
(In reply to Jamie Pate from comment #1) > I've just experienced another (possibly related?) issue with focus on a > number. checking the offsetWidth of an unrelated element seems to trigger > focus events on the focused <input type=number> (causing infinite recursion > in this case) Please file a separate bug with a testcase.
![]() |
||
Comment 5•8 years ago
|
||
(In reply to obrufau from comment #0) > Create a <input type="number">, append it to the DOM, and .focus() it. > > Before receiving the focus event, it receives a blur event. The same thing happens if the element is already in the DOM but display:none, then script changes it to display:block and calls focus() on it.
![]() |
||
Comment 7•8 years ago
|
||
(In reply to Victor Homyakov from comment #2) > Calling `focus()` synchronously right after insertion into DOM results in > three events: blur, focus, focus. The difference between your example and the original reporters is that the original reporters test is inserting the input element before the document has finished loading, whereas you are inserting it after. That is probably what makes the difference between firing an extra blur vs. extra focus and blur event.
![]() |
||
Comment 8•8 years ago
|
||
(In reply to Jimmy Gaussen from comment #3) > I have an issue that might be related. I have a focused field of a given > type. When changing its type to "number", a `blur` and another `focus` event > are immediately triggered. That's covered by bug 981248.
![]() |
||
Updated•8 years ago
|
Comment 10•8 years ago
|
||
In bug 1189748 this issue breaks google.com's search result page (although only if you search for specific formulas and want to alter input in its graph viewer)
Updated•6 years ago
|
Comment 13•6 years ago
|
||
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=1012818
Comment 14•5 years ago
|
||
I tested this with the latest FF Nightly 67.0a1(2019-03-12) on Windows 10 and Mac OS X 10.14 and I can't reproduce the issue, the input type from the attachment is focused.
obrufau, can you please retest this with the latest Nightly? You can download it from here: https://www.mozilla.org/en-US/firefox/nightly/all/
Comment 15•5 years ago
|
||
I can reproduce with the latest Nightly (2019-03-16 124ee436c421) on Windows 10 1803.
You need to open the console and load the attachment, then you will see the blur event:
Blur
Focus
In Chromium I only get
Focus
Comment 16•5 years ago
|
||
Hi Oriol,
I've compared Nightly with Chromium and in both cases, I have the same result. Bur Focus. Please see this print screen: https://imgur.com/a/nhQGPXW
Comment 17•5 years ago
|
||
Your screenshot shows that in Firefox you are getting a blur event before the focus one, this doesn't happen in Chromium.
Comment 18•5 years ago
•
|
||
Ok, I understand now what is the issue here. Thanks for your help.
I also tested this on Mac OS X 10.14 and the issue is reproducible.
The Release 66 version, Beta 67.0b1and Nightly 68.0a1 (2018-03-18) are affected by this issue, I will update the tracking flags.
Updated•5 years ago
|
Updated•5 years ago
|
Comment 20•5 years ago
|
||
Hi Mirko, while you're on other input issues recently, could you please look at this and relevant see-also ones? Thank you!
Assignee | ||
Comment 21•5 years ago
|
||
To determine the current state, I've tried the following reproductions:
-
The one in the description:
Most of the time the triggered events are in the following order: blur, blur, focus, focus.
However, sometimes the first blur was missing. -
The one in comment #2:
- Without delay: blur, focus, focus.
- With delay: focus.
Assignee | ||
Comment 22•5 years ago
•
|
||
When multiple blur and focus events are triggered, the problem seems to be: in HTMLInputElement::Focus
the numberControlFrame
isn't set (and probably not constructed) yet. The control flow is as follows:
HTMLInputElement::Focus
->Element::Focus
-> ... ->nsFocusManager::SetFocus
->nsFocusManager::SetFocusInner
->nsFocusManager::CheckIfFocusable
-> ... ->nsIPresShell::FlushPendingNotifications
-> ... ->nsCSSFrameConstructor::ConstructFrameFromItemInternal
->nsCSSFrameConstructor::ProcessChildren
->nsCSSFrameConstructor::GetAnonymousContent
->nsNumberControlFrame::CreateAnonymousContent
.
When exactly one focus event is triggered, that frame always seems to be set. This can be achieved when delaying the call to focus
after the input element has been attached to the DOM (as described in comment #2). In that case:
nsRefreshDriver::Tick
->nsIPresShell::FlushPendingNotifications
-> ... ->nsCSSFrameConstructor::ConstructFrameFromItemInternal
-> ... ->nsNumberControlFrame::CreateAnonymousContent
creates the anonymous content.- The number control frame seems to be set somewhere in
nsCSSFrameConstructor
too. - When
HTMLInputElement::Focus
is called, it can properly focus the text control of the<input type="number">
.
Assignee | ||
Updated•5 years ago
|
Assignee | ||
Comment 23•5 years ago
|
||
-
Avoids undesired bluring and focusing of '<input type="number">' and its nested elements.
-
Add tests for two scenarios where this could occur.
Assignee | ||
Comment 24•5 years ago
|
||
A try run corresponding to the review. The few failures are not related to this change. Requesting check-in.
Assignee | ||
Updated•5 years ago
|
Comment 25•5 years ago
|
||
Pushed by nbeleuzu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ee8e96e5d015
ensure all frames for '<input type="number">' are created before choosing the nested element to be focused. r=smaug
Comment 26•5 years ago
|
||
bugherder |
Updated•5 years ago
|
Description
•