1

I ran into some very weird behaviour in regards to .hasOwnProperty() and the ValidityState object.

In both IE (11) and FF (26), calling .hasOwnProperty() on ValidityState always returns false, even though the property is definitely set. In Chrome (33.0.1750.154 m) it seems to work fine.

Here's the code I used to test (or check out the JSFiddle).

<input type="text" id="dummy" required />
<ul id="properties"></ul>

var  oField = document.getElementById('dummy')
,oList  = document.getElementById('properties');

oField.addEventListener('change', function() {
    oList.innerHTML = '';
    for (var sProperty in oField.validity) {
        var oLi = document.createElement("li");

        oLi.innerHTML = sProperty + '[hasOwnPropertyValue=' + oField.validity.hasOwnProperty(sProperty).toString() + ']';
        oList.appendChild(oLi);
    }
});

Am I doing something wrong here or is the browser not handling this correctly? I for one, am stumped!

EDIT: Posted a bugby example... I blame fridays

JSFiddle ValidityState & .hasOwnProperty

Chris
  • 44
  • 7
  • 1
    I would not do this sort of thing on DOM elements. They are host objects - JavaScript doesn't "own them" - it just interacts with them via the DOM API, and they can behave pretty much any way they' like when you enumerate them. That said- the bug in your code is you're doing `oField.hasOwnProperty` instead of `oField.validity.hasOwnProperty` – Benjamin Gruenbaum Apr 04 '14 at 08:00
  • I blame fridays... Updated the JSfiddle to oField.validity.hasOwnProperty. I don't really get the DOM enumeration though because it's looping through the validity properties and just displaying them for testing purposes. – Chris Apr 04 '14 at 08:05
  • Nevermind the DOM enumeration, I get it now. How come the DOM elements can behave differently? You'd expect basic methods such as .hasOwnProperty to work like it should no matter the type of object or API. – Chris Apr 04 '14 at 09:33

0 Answers0