Discuss
  • Interesting ES5 side effect / window.hasOwnProperty(x) !== hasOwnProperty(x)

Interesting ES5 side effect / window.hasOwnProperty(x) !== hasOwnProperty(x)

# Wes Garland (14 years ago)

I bumped into something this morning that I thought might be worth pointing out -- mostly because I was surprised to have seemingly-valid ES3 code break on an ES5 browser without strict mode in play.

One of my developers has a habit of writing tests like

if (!hasOwnProperty("console")) // supply my own console object instead

This works fine on our deployment-target browsers, and up until very recently, on Firefox 4 betas. With the latest Firefox Minefield build, this same code throws a surprising (to me) error: "Error: can't convert undefined to object".

If I understand the relevant Mozilla bug correctly (and I'm not sure that I do) -- bugzilla.mozilla.org/show_bug.cgi?id=619283 -- this is because of the way bindings are looked up in ES5 10.2.1.2.4.

Interesting.

Comments? Obviously, the work-around is easy -- always invoke window.hasOwnProperty instead of hasOwnProperty -- but I wonder what other daemons lurk in the same corners.

# Mark S. Miller (14 years ago)

[+es5-discuss]

Hi Wes,

In Annex E, "Additions and Changes in the 5th Edition that Introduce Incompatibilities with the 3rd Edition", we list 27 potential compat problems, including the one you encountered:

In particular, in Edition 5 built-in functions that are specified to actually use the passed this value as an object typically throw a TypeError exception if passed null or undefined as the this value.

If you're looking for other daemons, I'd start there. If you find daemons that we missed, please let us know, as further errata may be called for. So far, AFAIK Annex E has done quite well.

# Juriy Zaytsev (14 years ago)

What's the point of checking existence of method via such strict test? Why hasOwnProperty and not much more commonly used typeof console != "undefined", window.console, etc.

Is there even a guarantee of any kind that method in question (e.g. console) is an own property of window or global object? What if it's not? It seems very much possible for method to be defined further up in the prototype chain (e.g. Window.prototype) in which case there would be a false negative.

This isn't related to the original question, but this kind of check just doesn't look right in the first place.

Or am I missing something?

# Wes Garland (14 years ago)

Or am I missing something?

Yes -- programmers do all kinds of crazy and unexpected things. :)