Bug 90502 - A variable created in the global scope does not cause a similarly-named property of the global object to be forced to "undefined"
Summary: A variable created in the global scope does not cause a similarly-named prope...
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-03 15:36 PDT by Jon-Carlos Rivera
Modified: 2012-07-04 13:23 PDT (History)
4 users (show)

See Also:


Attachments
Shows the compatibility bug (184 bytes, text/javascript)
2012-07-03 15:36 PDT, Jon-Carlos Rivera
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jon-Carlos Rivera 2012-07-03 15:36:14 PDT
Created attachment 150681 [details]
Shows the compatibility bug

For compatibility reasons, Firefox, Opera and Internet Explorer all force a variable defined in the global scope to hoist their "undefined" value into the global object and subsequently un-define (or hide) a global property with same name.

Attached example shows the problem. In all other browsers, (the exception being Safari and Chrome) the script will first print "undefined" and then print the number 42.

The reason for doing this in the name of compatibility is that new properties defined on the global object should never break existing scripts.

In WebKit browsers, if a script depends on the "undefined"-edness of a variable it will suddenly break if a property with that same name was added to the global object.
Comment 1 Jon-Carlos Rivera 2012-07-04 13:23:09 PDT
I also filed a bug report for Chrome, since it displays the same behavior: 

http://code.google.com/p/chromium/issues/detail?id=135666

The interesting part is:

---

> Comment 5 by rossb...@chromium.org, Today (2 hours ago)

> That behaviour is already implemented in Chrome 21, but was put behind a flag (--es52_globals) because of some compatibility issues we encountered. It will probably become the default in Chrome 22.