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>  

> 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
Opera - simply the best Internet experience
Received on Friday, 21 March 2008 10:03:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:25 UTC