1057858 - <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

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[obrufau]

Attachment: Demo

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

[Jamie Pate]

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

[Victor Homyakov]

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

[Jimmy Gaussen]

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

[Jonathan Watt [:jwatt]]

(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

[Jonathan Watt [:jwatt]]

(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

[Jonathan Watt [:jwatt]]

(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

[Jonathan Watt [:jwatt]]

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

Comment 10

[Hallvord R. M. Steen [:hallvors]]

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)

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

jwatt, would you have time to look at this?

Comment 12

[Jonathan Watt [:jwatt]]

I guess I should just admin the answer is no.

Comment 13

[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=1012818

Comment 14

[ovidiu boca[:Ovidiu]]

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

[Oriol Brufau [:Oriol]]

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

[ovidiu boca[:Ovidiu]]

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

[Oriol Brufau [:Oriol]]

Your screenshot shows that in Firefox you are getting a blur event before the focus one, this doesn't happen in Chromium.

Comment 18

[ovidiu boca[:Ovidiu]]

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.

Comment 20

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Mirko, while you're on other input issues recently, could you please look at this and relevant see-also ones? Thank you!

Comment 21

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

To determine the current state, I've tried the following reproductions:

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

2. The one in comment #2:

• Without delay: blur, focus, focus.
• With delay: focus.

Comment 22

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

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:

1. nsRefreshDriver::Tick -> nsIPresShell::FlushPendingNotifications -> ... -> nsCSSFrameConstructor::ConstructFrameFromItemInternal -> ... -> nsNumberControlFrame::CreateAnonymousContent creates the anonymous content.
2. The number control frame seems to be set somewhere in nsCSSFrameConstructor too.
3. When HTMLInputElement::Focus is called, it can properly focus the text control of the <input type="number">.

Comment 23

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

Attachment: Bug 1057858: ensure all frames for '<input type="number">' are created before choosing the nested element to be focused.

• Avoids undesired bluring and focusing of '<input type="number">' and its nested elements.

• Add tests for two scenarios where this could occur.

Comment 24

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

A try run corresponding to the review. The few failures are not related to this change. Requesting check-in.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
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

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/ee8e96e5d015