791653 - Can't type in inputs with type="number" when "type to search" is enabled and the dom.experimental_forms preference is set

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Yann Brelière]

Since Firefox 17 (currently Aurora), I can't type in inputs of type="number".
The field takes the focus, I can copy/paste ctrl+v, I can enter an autocompleted value, press backspace or delete once there is a value, etc.
But I can't type a letter (understandable) nor a number: it starts searching on the page as soon as I press a character.
It works fine when I disable "Search for text when I start typing".

I have attached a simple testcase: I can type in the 3 latter fields, but not the first one.
http://jsfiddle.net/yanndinendal/wr9CL/

Comment 1

[(mostly gone) XtC4UaLL [:xtc4uall]]

FWIW, this is WFM on Nightly/Windows 7.

Comment 2

[Yann Brelière]

Oh. :( I just tested on a clean profile and I don't have the problem.
But I also tested in "safe mode" and the problem is still there, so it's not an add-on problem (I don't know if safe mode disables other things).

Comment 3

[Boris Zbarsky [:bzbarsky]]

Does copying the prefs.js from the non-working profile to the clean profile make the clean profile not work?

Comment 4

[Yann Brelière]

Sorry for the delay. Thanks :bz, I can confirm that putting my prefs.js file in a new, clean profile does trigger the bug. I have copied the file in the jsfiddle: http://jsfiddle.net/yanndinendal/wr9CL/1/.

Comment 5

[Boris Zbarsky [:bzbarsky]]

  user_pref("dom.experimental_forms", true);

is what's doing this.

I believe in a desktop build, which doesn't have any actual support for type="number" what this does is simply not hook up an editor to the input at all, so the observed behavior makes sense.

Mounir, is this expected behavior if someone flips this pref for the moment?

Comment 6

[Mounir Lamouri (:mounir)]

I never tried to use the element with "Search for text when I start typing" enabled and I have no idea why this is behaving like that with this option activated.
However, <input type='number'> is experimental on desktop, as the about:config entry says. I'm planning to work on implementing the desktop UI soon (next quarter) so I will hopefully be able to have a deeper look on that bug.

Comment 7

[Yann Brelière]

See also bug 912511.

Comment 9

[Mark Straver]

It seems the problem is somewhere in commandDispatcher.focusedElement.mozIsTextField() that apparently does some specific checking for mobile and flags the "experimental" fields as "not a text field" which in turn allows FAYT to be triggered on the inputs instead of being able to type in it.
I didn't dig any deeper since it becomes convoluted rather quickly and I lost the thread of it when trying to read through the code.

Comment 10

[Jonathan Watt [:jwatt]]

Fixed by the work for bug 344616.

Comment 11

[Yann Brelière]

Yes, thanks! :)

Comment 12

[Petruta Horea [:phorea], Desktop QA]

The provided URL is no longer available.
Is there another link where I could check that this is fixed?
Thank you!

Comment 13

[Yann Brelière]

Sorry, I think I accidentaly deleted this fiddle. But I can confirm this bug is fixed. You can use any page with an <input type="number" />

Comment 14

[Petruta Horea [:phorea], Desktop QA]

Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0		

Reproduced in Firefox 18.0.2.
Verified as fixed on latest Aurora 29.0a2, buildID 20140312004002.