RE: XHR tests

"> Thanks for going through these Hallvord! Some comments / questons below.
> (Also questions regarding changing XMLHttpRequest. So if the rest of
> the WG could review as well that'd be apprecated.)"

Thanks for making the time to create the tests. I'd love to take a look and will review the tests next week.
Cheers,

-----Original Message-----
From: public-webapi-request@w3.org [mailto:public-webapi-request@w3.org] On Behalf Of Hallvord R. M. Steen
Sent: Friday, March 21, 2008 3:04 AM
To: Anne van Kesteren; Charles McCathieNevile; Web API WG (public)
Subject: Re: XHR tests


On Mon, 25 Feb 2008 23:56:25 +0900, Anne van Kesteren <annevk@opera.com>
wrote:

> Thanks for going through these Hallvord! Some comments / questons below.
> (Also questions regarding changing XMLHttpRequest. So if the rest of the
> WG could review as well that'd be apprecated.)

I second that - more eyes on our tests-in-progress would be good :-)

>>> http://tc.labs.opera.com/apis/XMLHttpRequest/open/016.htm
>>
>> Tests creating an XMLHttpRequest instance, changing the URL of
>> associated document, and loading a relative URL. Assumes that URL
>> should be resolved according to location of original document in said
>> window.
>>
>> Opera 9.5 - fails because it throws INVALID_STATE_ERROR on send()
>> IE7 - fails because it throws on open()
>> Firefox 2 - fails because it throws on open()
>> Safari (version 3 on Windows btw) - fails because it fails to load the
>> new document when location is set (!??)
>>
>>> http://tc.labs.opera.com/apis/XMLHttpRequest/open/024.htm
>>
>> Same results as 016.htm
>
> These probably fail because everyone resolves URIs in different ways.
> The specification defines a clear way to do this, but if there is a
> better alternative I'm open to suggestions.

Personally I think throwing is quite a natural thing to do in this
condition (the document/URL of window has changed since the XHR object was
created) and when 3 out of 4 major implementations already do so we
probably don't introduce compat problems by specifying that.


>>> http://tc.labs.opera.com/apis/XMLHttpRequest/open/031.htm
>>
>> Tests creating an XHR instance from the XMLHttpRequest object of an
>> IFRAME, removing the IFRAME from the DOM, adding a BASE href element
>> with DOM methods to the document in the removed IFRAME, and using the
>> XHR instance. (Anne getting rather creative/evil here :-) )
>>
>> IE7 - my IE7 actually says pass here!
>> Opera / Safari / Firefox: all three kill the script environment of the
>> window object when the IFRAME is removed from the DOM. Hence trying to
>> add BASE href throws and the test says failed.
>>
>> When to kill and garbage collect the script environment inside the
>> IFRAME when it's removed from DOM is obviously not the XHR spec's
>> business. I suggest this test is relaxed to accept several
>> implementation choices, either shutting down the script environment and
>> resolving URL by original IFRAME src or doing whatever IE does. We
>> should have a corresponding evil security test or two checking that
>> removing the IFRAME won't confuse the browser into allowing x-domain
>> requests it shouldn't.
>
> I rather liked the behavior of Internet Explorer 7.

I still think we can't make implementations rewire their garbage
collection to pass an extreme corner case test. This sort of stuff simply
should not be specified here. :-p

> Changing this would require some rewording of the definition of document
> pointer in section 4 probably:
>
>    http://dev.w3.org/2006/webapi/XMLHttpRequest/#xmlhttprequest
>
> If we want that suggestions are welcome.

What about just throwing if the associated window is closed or removed
 from the DOM?


--
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience

Received on Friday, 21 March 2008 23:38:22 UTC