This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10340 - The [OverrideBuiltins] annotation on the Window interface IDL block should be removed because it breaks sites
Summary: The [OverrideBuiltins] annotation on the Window interface IDL block should be...
Status: CLOSED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://dev.w3.org/html5/spec/browsers...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-10 14:33 UTC by Adrian Bateman [MSFT]
Modified: 2010-10-04 14:47 UTC (History)
4 users (show)

See Also:


Attachments

Description Adrian Bateman [MSFT] 2010-08-10 14:33:30 UTC
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.
Comment 1 Ian 'Hixie' Hickson 2010-09-10 23:07:02 UTC
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>?
Comment 2 Adrian Bateman [MSFT] 2010-09-11 18:10:50 UTC
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>
Comment 3 Ian 'Hixie' Hickson 2010-09-28 01:31:50 UTC
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.
Comment 4 Ian 'Hixie' Hickson 2010-09-28 01:37:30 UTC
http://html5.org/tools/web-apps-tracker?from=5522&to=5523
Comment 5 Adrian Bateman [MSFT] 2010-09-30 16:11:21 UTC
Looks good. Thanks!