Closed Bug 791653 Opened 9 years ago Closed 7 years ago
Can't type in inputs with type="number" when "type to search" is enabled and the dom
.experimental _forms preference is set
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/
FWIW, this is WFM on Nightly/Windows 7.
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).
Does copying the prefs.js from the non-working profile to the clean profile make the clean profile not work?
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/.
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?
Summary: Can't type in inputs with type="number" when "type to search" is enabled → Can't type in inputs with type="number" when "type to search" is enabled and the dom.experimental_forms preference is set
Target Milestone: mozilla17 → ---
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.
See also bug 912511.
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.
Yes, thanks! :)
Assignee: nobody → jwatt
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Version: 17 Branch → 28 Branch
The provided URL is no longer available. Is there another link where I could check that this is fixed? Thank you!
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" />
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.