Failure via forward thinking

The_Assimilator

Today we got a call from a client that an app we wrote for them is giving validation errors. I can't repro it locally, so I ask for a bit more info. Eventually we discover the client's using IE 10... the last time dev, and hence testing, was done on this app, was when IE 10 didn't even exist. (It's a JSP webapp originally written when Hibernate was still new and cool.)

Client doesn't want to downgrade to IE9 for various reasons, and I can't see any obvious reason why the app should break in IE 10, so I install IE 10 and fire up the app with the Developer Console running. Stepping through the validation methods, I see that the JavaScript is checking for min and max attributes when validating input boxes. But min and max were only added in HTML5... were the original coders prescient?

Since this is TDWTF, you already know the answer. In their infinite wisdom, the devs decided to add custom attributes to HTML tags for validation purposes. Two of these validation attributes happened to be named the same as those made official by HTML5. The JavaScript that decides whether to validate fields does the following:

if (typeof(textbox.min) != 'undefined' || typeof(textbox.max) != 'undefined') {
  var value = parseFloat(textbox.value), min = parseFloat(textbox.min), max = parseFloat(textbox.max);
if ((!isNaN(min) && min > value) || (!isNaN(max) && max < value)) {

// puke up validation error and die

}

}

Unfortunately, IE 10's implementation of HTML5's min and max attributes ensures that ALL input fields have implicit min and max attributes. So "typeof(textbox.min) != 'undefined'" is always true, and the validation tries to validate EVERYTHING. But that's not the end! Because of JavaScript's loose typing, parsing an empty string as a float yields zero. Hence isNaN(min) and isNaN(max) always return false. The end result is the code evaluates to this:

if (true || true) {
  var value = parseFloat(textbox.value), min = parseFloat(textbox.min), max = parseFloat(textbox.max);
if ((!false && 0 > value) || (!false && 0 < value)) {

// we always get here unless value == 0

}

}

The fix? Ensure textbox.min and .max aren't empty strings, in addition to checking if they're undefined. Works on all versions of IE, client is happy, bug is closed. Well, at least I didn't have to change any of the Java code.

blakeyrat

Not really any WTFs here.

MustBeUsersFault

an old doctype should be enough to return to the old behavior. no ?

Ragnax

@MustBeUsersFault said:

an old doctype should be enough to return to the old behavior. no ?

No; any valid doctype will still default to IE10 Standards mode. Setting the X-UA-compatible header may work, but that depends on whether or not the input validation additions are removed in IE10's IE{x < 10} Standards mode. Microsoft is unusually inconsistent on that front.

The proper solution is to implement custom attribute markup with data-* attributes as per the HTML5 recommendation. These are guaranteed to never clash with new HTML functionality.

@blakeyrat said:

Not really any WTFs here.

There are 2 in fact:

The original developers not using data-* attributes and inviting the name-clash.
The TS 'fixing' things by piling on more detection instead of fixing the original problem.