W3C home > Mailing lists > Public > public-webapi@w3.org > March 2008

Re: XHR tests

From: Hallvord R. M. Steen <hallvord@opera.com>
Date: Fri, 21 Mar 2008 19:04:24 +0900
To: "Anne van Kesteren" <annevk@opera.com>, "Charles McCathieNevile" <chaals@opera.com>, "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.t8c19mnra3v5gv@hr-opera.oslo.opera.com>

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 10:03:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 March 2008 10:03:52 GMT