CODEWITHSUNDEEP
javascriptgoogle-chromehtml-inputsoft-keyboardselection-api
scunliffe
scunliffe

Reputation: 63606

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

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:

Methods:

(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:

Upvotes: 13

Views: 4582

Answers (2)

scunliffe
scunliffe

Reputation: 63606

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

Upvotes: 4

Andy E
Andy E

Reputation: 344675

Depending on the use case, there may be a more appropriate (albeit elaborate) workaround. For instance, in order to add text at the current position of the cursor, you can do the following (tested in Chrome):

var len, pre, post,

    // Currently focused element
    a = document.activeElement,

    // Get current selection
    s = window.getSelection();

// Delete any existing contents
s.deleteFromDocument();

// Keep moving selection backward until the length stops increasing
do {
    len = String(s).length;
    s.modify('extend', 'backward', 'line');
}
while (String(s).length !== len);

// Store the selection, then delete it
pre = String(s);
s.deleteFromDocument();

// Keep moving selection forward until the length stops increasing
do {
    len = String(s).length;
    s.modify('extend', 'forward', 'line');
}
while (String(s).length !== len);

// Store the selection, then delete it
post = String(s);
s.deleteFromDocument();

// Recreate the contents with the new text added
a.setAttribute('value', a.defaultValue);
a.value = pre + txt + post;

// Move the selection to after the new text
a.select();
s = window.getSelection();
s.collapseToEnd();

while (len-- > 0)
    s.modify('move', 'backward', 'character');

There are limitations to this approach that might need even more elaborate solutions, too, such as when a different value is returned than text is selected (which may be the case for arabic domain names in a type="email" input, for example).

Sadly, there's a bug that prevents this workaround from working in Firefox/Gecko, but at least Firefox still allows Selection API on <input type="email">.

Upvotes: 0

Related Questions