<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

RESOLVED FIXED in Firefox 68

Status

()

defect
P3
normal
RESOLVED FIXED
5 years ago
4 months ago

People

(Reporter: obrufau, Assigned: mbrodesser)

Tracking

unspecified
mozilla68
x86
Windows XP
Points:
---

Firefox Tracking Flags

(firefox66 wontfix, firefox67 wontfix, firefox68 fixed)

Details

Attachments

(2 attachments)

Posted file 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).
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)
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).
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".
(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.
(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.
Duplicate of this bug: 1176904
(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.
(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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 981248
Summary: .focus() on a number input fires a blur event → <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
Duplicate of this bug: 1189748
See Also: → 1211895
See Also: → 1012818
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)
jwatt, would you have time to look at this?
Flags: needinfo?(jwatt)
I guess I should just admin the answer is no.
Flags: needinfo?(jwatt)
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=1012818

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/

Flags: needinfo?(obrufau)

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
Flags: needinfo?(obrufau)

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

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

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.

Priority: P5 → P3
Duplicate of this bug: 1542483

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

Flags: needinfo?(mbrodesser)

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.
Flags: needinfo?(mbrodesser)

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">.
Assignee: nobody → mbrodesser
  • Avoids undesired bluring and focusing of '<input type="number">' and its nested elements.

  • Add tests for two scenarios where this could occur.

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

Keywords: checkin-needed

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

Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
You need to log in before you can comment on or make changes to this bug.