Open Bug 981248 Opened 6 years ago Updated 2 months ago

<input> has focus/blur issues when it has focus and its type changes to/from type=number

Categories

(Core :: Layout: Form Controls, defect, P2)

defect

Tracking

()

Webcompat Priority P1
Tracking Status
firefox27 --- unaffected
firefox28 --- affected
firefox29 --- affected
firefox30 --- affected

People

(Reporter: jchen, Unassigned, NeedInfo)

References

(Blocks 2 open bugs, )

Details

(Whiteboard: [webcompat:p1])

Attachments

(3 files)

The first input in the test case switches its type from 'text' to 'number' in its onfocus handler, and switches back in onblur. However, after it switches to number, it no longer accepts any input. This happens because the focus is still on the parent element rather than on the (newly created) anonymous child element.

I think the block at [1] is supposed to fix this problem, but it doesn't actually work because the anonymous child is not bound to the document at that point, so nsFocusManager::SetFocus() fails. SetFocus() wouldn't work in any case, because assuming the anonymous child is focused, the parent input element will get a blur event; during the blur handler, the input type is switched back to text and everything is destroyed; we still don't get a focused number input.

I think we have to make some changes to nsFocusManager to fix this. 

[1] http://mxr.mozilla.org/mozilla-central/source/layout/forms/nsNumberControlFrame.cpp?rev=63a4ad62401a#359
Severity: normal → minor
Priority: -- → P4
See Also: → 1122889
There are other related issues when changing the type. For example, bug 1057858 comment 3.

https://jsfiddle.net/5gc7upLj/
Summary: Input is not focused when switching input type to number on focus → <input> has focus/blur issues when it has focus and its type changes to/from type=number
See Also: → 1057858
Here is a version with all the current input types: http://jsfiddle.net/5gc7upLj/2/

This confirms that it only occurs with the number type.
This breaks the "Search by flight number" status functionality on westjet.com's mobile site.

(If I had to guess, sites do this because they want the "number" keypad (on mobile), but not the ugly spinners that they can't turn off.)
Bumping up to P3 because this breaks real sites (not sure anyone uses priority values, but all the same...)
Severity: minor → normal
Priority: P4 → P3
Wasted hours tracking this down. Rather subtle. Reported at https://stackoverflow.com/questions/38770152/firefox-blurs-when-changing-the-input-type where it was blamed on AngularJS.

However here's a demo of it happening with jQuery. The field can only be edited once in Firefox. https://jsfiddle.net/BobStein/4mL902vo/7/

Changing an input field from text to number causes the field to spontaneously blur.
See Also: → 1211895
Flags: webcompat+
Whiteboard: [webcompat:p3]
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
Whiteboard: [webcompat:p3] → [webcompat:p2]
I had this WIP patch around, which simplifies a bunch of stuff and should fix this as well, but needs a bit more work.

I didn't want to lose track of it.
Duplicate of this bug: 977259
Whiteboard: [webcompat:p2] → [webcompat:p1]
Priority: P3 → P2

See bug 1547409. Migrating webcompat priority whiteboard tags to project flags.

Webcompat Priority: --- → P1
Attached file wpt.html

I could not find a test like this already in the web platform tests (or the Blink or WebKit test suites), so here is a testharness.js WPT (like uievents/click/auxclick_event.html) which should do the trick.

I had a patch to stop using the hacky anonymous text control for number inputs somewhere in bugzilla, I should probably rescue that patch.

Flags: needinfo?(emilio)

Oh, it was attached to this bug. :-)

I'll try to rebase it.

I have https://treeherder.mozilla.org/#/jobs?repo=try&revision=9b09ae8ee993fb9c9c055118153ef8b32e85b826, which kinda works. I just pushed it to try to see where it stands.

Flags: needinfo?(emilio)

(Didn't want to drop the ni?)

Flags: needinfo?(emilio)

So from the try run:

  • Needs some a11y fixes (this should be easy-ish).
  • I broke some font inflation stuff looks like, and need to check the placeholder / preview stuff. I probably need to tweak some reflow bits or some CSS there to make layout correct and consistent.
  • There's an assert that needs investigation. Potentially related to the above.
  • I broke localization of the number but that (a) it is untested (b) it is bogus and (c) no other browser does it.

So all in all seems a bit of work, but probably workable.

Flags: needinfo?(emilio)
Flags: needinfo?(emilio)
Depends on: 1565214

This is also breaking Sunlife's page on Android Firefox browsers, because it causes the on-screen keyboard to never be brought up and users cannot type in their age/etc.

See Also: → 1495482
You need to log in before you can comment on or make changes to this bug.