How to overcome WhatWG/W3C/Chrome version 33.0.1750.146 "regression bug" with <input type="number"/> fields

Question

I put the words "regression bug" in quotes as there is obviously some mixed opinions on this. For full details track Bug 24796 in Bugzilla.

In short Google Chrome implemented changes according to the latest version of the WhatWG specs: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#input-type-attr-summary that removed the following properties and methods from <input type="number"/> fields.

Properties:

• selectionStart
• selectionEnd

Methods:

• select()
• setSelectionRange(start, end)

(there are others but these are the common key ones used)

The methods are defined if you inspect a "numeric" instance of the HTMLInputElement however attempting to call the methods or request the properties will throw an exception. :-(

IMHO this is a bug (since functionality has been removed with nothing gained... and there are 1,000's of web sites/applications that provide extended behavior to these numeric input fields via JavaScript... but I digress (for those that wish to battle it out please use the bug post listed above))

TL;DR

For usability purposes I most certainly want and plan to continue using <input type="number"/> fields as they provide a "hint" to the user agent that if on a mobile device (smartphone/tablet/?) that I would like to present the numeric keyboard when the field is focused vs. the default alpha keyboard.

However for the current version of Chrome (ver 33.0.1750.146) and any other browser that blindly implements this spec change I'd like to safely convert the rendered fields back to <input type="text"/>

Notes:

• Attempting to change these fields on the fly when modifying their contents has proven unsuccessful as the field loses it's selection range when the type attribute is changed.
• I do have a workaround solution I came up with which I'll post shortly, but I wanted to ensure this question/answer was here for all developers that encounter this issue

Answer 1

I've solved this with the following code:

function checkForInputTypeNumberBug(){
  var dummy = document.createElement('input');
  try {
    dummy.type = 'number';
  } catch(ex){
    //Older IE versions will fail to set the type
  }
  if(typeof(dummy.setSelectionRange) != 'undefined' && typeof(dummy.createTextRange) == 'undefined'){
    //Chrome, Firefox, Safari, Opera only!
    try {
      var sel = dummy.setSelectionRange(0,0);
    } catch(ex){
      //This exception is currently thrown in Chrome v33.0.1750.146 as they have removed support
      //for this method on number fields. Thus we need to revert all number fields to text fields.
      $('input[type=number]').each(function(){
        this.type = 'text';
      });
    }
  }
}
$(document).ready(function(){
  checkForInputTypeNumberBug();
});

I've made it a standalone function as I have cases where the fields are loaded via AJAX and I need to be able to call the function on the fly.

This code handles older IE versions where attempting to set the type will fail as well as handle the exception in Chrome (on a dummy element) so that pages can overcome this behavior change.

Update: As per @Andy E's suggestion around using the inputmode attribute (currently unsupported) I've created a bug to try and prioritize the implementation of inputmode before user agents remove the selection APIs: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26695