Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
177 views
in Technique[技术] by (71.8m points)

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

  • 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
See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

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


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...