As of Chrome 33, the keyboard does not work on inputs where 'type=email' or 'type='number'

[edazdarevic]

I see this error in the console:

Uncaught InvalidStateError: Failed to read the 'selectionStart' property from 'HTMLInputElement': The input element's type ('email') does not support selection.

Probably because of this
https://code.google.com/p/chromium/issues/detail?id=324360

[Mottie]

Hmm, so should I go ahead and only support "text", "search", "url", "telephone" and "password" type inputs?

This all seems kind of silly to me to not support caret positioning in all other input types.

[BrandonLWhite]

Ugh! I ran right into this roadblock today. I finally got some time to spend checking out the latest working branch changes, and this issue pretty much derailed me. Others are having hassles because of this recent change in Chrome.

I tried a few kludges, including setting the input type to "text" temporarily in the code then back to "number". I also tried bypassing the caret stuff. Neither really worked out. The keystrokes would insert at the beginning of the input when I tested it out.

I agree with you -- it's very annoying that they have borked these input types in the name of 'adhering to spec'. I'm not clear what implementing these restrictions on selectionStart solves in practice. Seems to me like it's going to break a lot of apps out there.

I'm mulling over removing type="number" for my jQuery Mobile stuff, and maybe using a data- attribute as the selector. It's annoying, but I'm not seeing any alternative.

[BrandonLWhite]

Relevant Bug/discussion over on w3.org

Go add your 2-cents if you're inclined.

[Mottie]

I wonder if this would help....

If an input is of a type that doesn't support caret positioning, the plugin will instead create a preview with an input of "text" type to handle all the caret positioning and interactions. Then when the user accepts the changes, it is added back to the original input.

Of course this would require you setting the usePreview option to true.