Closed
Bug 791653
Opened 12 years ago
Closed 11 years ago
Can't type in inputs with type="number" when "type to search" is enabled and the dom.experimental_forms preference is set
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
VERIFIED
FIXED
mozilla29
People
(Reporter: yannbreliere, Assigned: jwatt)
References
()
Details
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•12 years ago
|
||
FWIW, this is WFM on Nightly/Windows 7.
Reporter | ||
Comment 2•12 years ago
|
||
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•12 years ago
|
||
Does copying the prefs.js from the non-working profile to the clean profile make the clean profile not work?
Updated•12 years ago
|
Flags: needinfo?(yannbreliere)
Reporter | ||
Comment 4•12 years ago
|
||
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/.
Flags: needinfo?(yannbreliere) needinfo?(yannbreliere) → needinfo+
![]() |
||
Comment 5•12 years ago
|
||
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 → ---
Comment 6•12 years ago
|
||
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.
Reporter | ||
Comment 7•11 years ago
|
||
See also bug 912511.
Comment 9•11 years ago
|
||
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.
Reporter | ||
Comment 11•11 years ago
|
||
Yes, thanks! :)
![]() |
Assignee | |
Updated•11 years ago
|
Assignee: nobody → jwatt
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Version: 17 Branch → 28 Branch
Updated•11 years ago
|
Updated•11 years ago
|
QA Contact: petruta.rasa
Comment 12•11 years ago
|
||
The provided URL is no longer available.
Is there another link where I could check that this is fixed?
Thank you!
Flags: needinfo?(yannbreliere)
Reporter | ||
Comment 13•11 years ago
|
||
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" />
Flags: needinfo?(yannbreliere)
Comment 14•11 years ago
|
||
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.
Description
•