Re: [XHR] Constructor behavior seems to be underdefined

On Sat, 31 Mar 2012 13:21:40 +0200, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> I agree; it's just that the spec doesn't actually say that.  Testing it  
> in the test suite is a good start, though.  ;)

Yeah fair enough. I'm glad people still review the spec :-)


> 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.

I was thinking of EventSource and how it resolves URLs. For some reason I  
thought it was similar for Image and such. XMLHttpRequest resolves them  
relative to the XMLHttpRequest Document whereas EventSource uses the entry  
script's base URL. HTMLImageElement seems to resolve them similarly to  
XMLHttpRequest (at least per the specification).


>> 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).

Okay, so maybe that should be added again when someone next updates the  
test suite.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Saturday, 31 March 2012 11:49:05 UTC