Hi mobile folks,
I've just landed a series of patches on mozilla-inbound on the way to giving
gecko a complete implementation of <input type=number> (that is, not just the
minimal implementation we have for fennec/b2g). These patches passed Try, but
there are two significant things to note (and a bonus item):
1) Consider checking HTMLInputElement.ownerNumberControl before handling a
<input type=text>.
Code that relies on looking at the focused element, checking whether it's an
instance of HTMLInputElement, and then doing input-type dependent things, may
end up doing the wrong thing. Specifically you should know that <input
type=number> now contains an anonymous shadow tree that results in its DOM
looking like this:
input - type=number
div - outer wrapper with "display:flex"
input - text input field
div - spin box wrapping up/down arrow buttons
div - spin up (up arrow button)
div - spin down (down arrow button)
The important thing to note is the nested <input type=text>. It is this
anonymous _nested_ <input> that gets focus when a user tries to focus any other
part of the tree (including the <input type=number> itself). As a result, code
that looks at focused HTMLInputElement instances and does things depending on
the type of that input may take the wrong actions.
For example, I had to fix a point in the IME code where it looked at the focused
field, saw it was text, and brought up the normal keyboard (bug 939635). What it
now has to do is first check ownerNumberControl on the input and, if non-null,
use the ownerNumberControl (the non-anonymous ancestor <input type=number>) to
make its decision about which IME to bring up.
(BTW, in case anyone is wondering, the spin box wrapping div is |display:none|
for fennec/b2g.)
2) The styling of <input type=number> will currently be a bit off.
Specifically, when such an element is focused, it will not get the :focus CSS
styling. This is bug 940764. I think this is just a case of fixing up
android/themes/core/content.css somehow. If anyone wants to do that feel free to
take the bug.
3) Oh, and one more thing - use HTMLInputElement.mozIsTextField()
There's a scary amount of code scattered around the tree making decisions about
whether a form field is text or not based on checking a list of hand written
types. This is really prone to breakage, probably responsible for some existing
assertions and in fact breakage, and I won't be shocked if my patches reveal
some more. I had to fix up some places to get my patches passing Try, but I bet
there are others. Please use mozIsTextField():
https://mxr.mozilla.org/mozilla-central/source/dom/webidl/HTMLInputElement.webidl#169
Anyway, I hope the above helps save some wasted time if anyone notices any
unexpected issues that are a result of my landing.
Regards,
Jonathan
_______________________________________________
mobile-firefox-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/mobile-firefox-dev
