Re: [XHR] Constructor behavior seems to be underdefined

On 3/31/12 4:17 AM, Anne van Kesteren wrote:
>> w1.XMLHttpRequest = w2.XMLHttpRequest;
>> var xhr = new w1.XMLHttpRequest();
>>
>> What's the document associated with xhr? Is it w1.document,
>> w2.document, or window.document? The concept "the Window object for
>> which the XMLHttpRequest interface object was created" doesn't seem to
>> be defined anywhere....
>
> So this was defined this way the last time you brought this up. I
> believe it should be w2.document

I agree; it's just that the spec doesn't actually say that.  Testing it 
in the test suite is a good start, though.  ;)

> which is different from how most
> constructors behave (e.g. Image)

Huh.  What does Image do differently?  This testcase:

   <!DOCTYPE html>
   <iframe></iframe>
   <iframe></iframe>
   <script>
     function f () {
       var w0 = frames[0];
       var w1 = frames[1];
       w0.Image = w1.Image;
       var img = new w0.Image();
       alert(img.ownerDocument == w1.document);
     }
     window.onload = f;
   </script>

alerts true in Gecko, Chrome, Safari, and Opera.  No IE on hand right 
now...  That would be consistent with associating the image with the 
document that the constructor object is associated with.

> The testsuite does not test
> w1.XMLHttpRequest = w2.XMLHttpRequest explicitly, because nothing should
> happen there except referencing the interface object from elsewhere.

Unless some implementor decides to use the this binding of the function 
call instead of some sort of out-of-band association state, yes? 
Similar for:

   var xCtor = w2.XMLHttpRequest;
   var xhr = new xCtor;

(this is not entirely hypothetical; such a bug was almost introduced to 
Gecko recently because the spec was not clear; hence the thread).

-Boris

Received on Saturday, 31 March 2012 11:22:10 UTC