10340 2010-08-10 14:33:30 +0000 The [OverrideBuiltins] annotation on the Window interface IDL block should be removed because it breaks sites 2010-10-04 14:47:41 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified All All CLOSED FIXED http://dev.w3.org/html5/spec/browsers.html#the-window-object P3 normal --- 1 adrianba ian ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 37334 0 adrianba 2010-08-10 14:33:30 +0000 Existing text: [OverrideBuiltins, ReplaceableNamedProperties] interface Window { ... New text: [ReplaceableNamedProperties] interface Window { ... In IE9, as in both Chrome and Firefoxs OverrideBuiltins implementation, OverrideBuiltins means check the custom named getter for the object, then check the prototype chain. This can be observed by looking at the behavior of OverrideBuiltins support on the HTMLFormElement in Firefox and Chrome (IE9 preview 4 gets it wrong but were fixing that): <form id=myForm> <input id=appendChild /> <img id=hasOwnProperty name=hasOwnProperty /> </form> document.getElementById(myForm).appendChild; // This is a reference to the <input> element, not the built-in appendChild DOM API. document.getElementById(myForm).hasOwnProperty; // This is a reference to the <img> element, not the built-in Object.prototype.hasOwnProperty API. So, in early IE9 builds, we applied this behavior to the Window interface just like the current spec says. However, this behavior breaks real websites because many, many websites use element ids that conflict with the built-in properties that they are expecting. In IE9, all DOM operations and properties are represented by ES5 data properties and accessor properties respectively. These DOM built-ins are looked up in the prototype chain, just like everything else. The accessors of the window object (e.g., the document accessor) are defined on Window.prototype, which is the prototype of the global object. The HTML5 spec defines an element with id=document. At that point, any window-scoped requests for the document built-in return an HTMLElement instance, instead of the built-in Document object, such as: document.getElementById; // Script error, because document is a reference to the specific HTMLElement type, which does not support the getElementById property. In our testing, Chrome doesnt support OverrideBuiltins on window, nor does Firefox. Opera does something else which is a different behavior than what we found with the other browsers when applying the HTMLFormElements definition of OverrideBultins to the window. Due to the browser interop matrix as well as the site-compat problem, we recommend removing the [OverrideBuiltins] annotation from the Window interface. 38867 1 ian 2010-09-10 23:07:02 +0000 Looks like it's more complicated than just removing OverrideBuiltins, because <iframe name=document> does override builtins in Chrome (not in Firefox). I wasn't able to test IE since I don't have access to a Windows install. Does IE [OverrideBuiltins] on Window for <iframe name=document>? 38882 2 adrianba 2010-09-11 18:10:50 +0000 In our testing, even Chrome6 does not [OverrideBuiltins] in the iframe case. They appear to first lookup the real "document" before getting the window from the iframe. If Chrome supported [OverrideBuiltins] for iframes, then we would expect both "doc" and "win" below to alert the Window--but that is not the case. To answer your question, both IE8 and IE9 do not OverrideBuiltins for <iframe name="document">. Here's our interop report and test case for your verification: <!DOCTYPE html> <html><head><title>window [OverrideBuiltins] and iframes</title></head> <body> <iframe name="document2" src="http://www.bing.com/"></iframe> <iframe name="document" src="http://www.google.com/"></iframe> <div id="toString"></div> <span id="testing"></span> <script> onload = function () { try { var spn = testing; // Confirm this functionality is supported } catch (ex) { } try { var doc = document; } catch (ex) { } try { var win = document2; } catch (ex) { } try { var func = toString; } catch (ex) { } // Results: Chrome6 Firefox3.6 IE8 IE9 alert(spn); // HTMLElement undefined HTMLSpanElement HTMLSpanElement alert(doc); // HTMLDocument HTMLDocument HTMLDocument Document alert(win); // DOMWindow Window Window Window alert(func); // [native code] [native code] [native code] [native code] } </script> </body> </html> 39642 3 ian 2010-09-28 01:31:50 +0000 EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Fair enough. 39643 4 ian 2010-09-28 01:37:30 +0000 http://html5.org/tools/web-apps-tracker?from=5522&to=5523 40199 5 adrianba 2010-09-30 16:11:21 +0000 Looks good. Thanks!