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

On Tue, 12 Feb 2008 02:37:37 +0100, Hallvord R. M. Steen  
<hallvord@opera.com> wrote:
>> http://tc.labs.opera.com/apis/XMLHttpRequest/open/011.htm
>
> Tests the value of .responseText for HEAD requests (Anne, slightly more  
> verbose TITLEs please!). Expects null.
>
> Opera 9.5 - buggy, ignore this
> IE7 - empty string
> Firefox 2 - empty string
> Safari - empty string
>
> I say fix spec and test and go with majority vote!

Yes. I suggested as much in my e-mail before this one.


>> http://tc.labs.opera.com/apis/XMLHttpRequest/open/012.htm
>
> Tests calling open() twice in a row on an async request (leaving out 3rd  
> argument to open() though, I assume a separate test tests if it defaults  
> to true)
>
> Opera 9.5 - fails because of a missing readyState 3 event
> IE7 - fails because onreadystatechange property is cleared by second  
> open() call
> Firefox 2 - fails because second open() call throws
> Safari - fails because it sends an extra readyState 0 event on second  
> open() call and omits readyState 3 event
>
> Wel, have fun discussing that..

The behavior in Internet Explorer 7 was an acknowledged bug by the IE Team.


>> http://tc.labs.opera.com/apis/XMLHttpRequest/open/013.htm
>
> Fails cross-browser because of 4 different implementations of the order  
> events should happen in on open() send() open()..

Same issue as 012 if I remember correctly.


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


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


>> http://tc.labs.opera.com/apis/XMLHttpRequest/responseText/002.htm
>
> Tests an infinite redirect loop and .responseText. Like open/011.htm it  
> flags an empty string as a failure and I think it would be better to  
> specify returning an empty string for compatibility with existing  
> implementations and possibly content.

Agreed. I will change this in the specification.


>> http://tc.labs.opera.com/apis/XMLHttpRequest/responseText/003.htm
>
> This is more like a demo than a test case, it doesn't return a pass/fail  
> to the framework and it doesn't really test what TITLE claims. (What it  
> *does* test is that readyState is 1 in the first event sent when you  
> call send() on a synchronous request..). Anne, please fix this test and  
> figure out what you meant to test with this script.

It's meant to test if the right exceptions are thrown, which is currently  
still an open issue. But so far it seems that nobody is objecting to not  
throwing exceptions. Once that is resolved I will fix this test (and 004).


>> http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/006.htm
>
> Tests getAllResponseHeaders() output if the request ends up in an  
> endless redirect loop. Assumes that it should return null.
>
> Opera 9.5 - fails because it returns actually returned headers
> Safari - fails because it returns an empty string
> IE 7 - fails because it returns an empty string
> Firefox 2 - fails because send() throws at some point (?!?)

We can make it return the empty string instead. Do we also want to do that  
for getResponseHeader() then in case of error conditions?


>> http://tc.labs.opera.com/apis/XMLHttpRequest/abort/008.htm
>
> Tests a specific sequence of method calls - open() async, send(),  
> abort(), open()
> Fails in all browsers because not all expected events are sent (or they  
> are sent in different order than expected)

Same as the other issues mentioned earlier.


>> http://tc.labs.opera.com/apis/XMLHttpRequest/send/003.htm

This one passes in Firefox 3 and IE7. Though the alert() statement should  
probably be removed.


>> http://tc.labs.opera.com/apis/XMLHttpRequest/send/005.htm
>> http://tc.labs.opera.com/apis/XMLHttpRequest/send/006.htm
>> http://tc.labs.opera.com/apis/XMLHttpRequest/send/007.htm
>> http://tc.labs.opera.com/apis/XMLHttpRequest/send/008.htm
>
> Think all these tests are broken because  
> http://tc.labs.opera.com/apis/XMLHttpRequest/send/support/content-type.script  
> doesn't do whatever it's supposed to. Anne?

I think they're part of some experiment I never finished.


>> http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/011.htm
>
> Same as 010 except it tests for first argument being undefined and IE  
> doesn't actually throw here.

Should we change the API so that undefined stringifies as IE does? Does IE  
stringify for the value too? And what does it do for null?


>> http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/020.htm
>
> Tests both arguments to setRequestHeader being null. Same results as  
> 010.htm

So null should throw? Hmm...


>> http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/021.htm
>
> Test is entirely broken because it is actually a PHP script which is  
> being sent in its entirety. (Hey, it's a feature! At last Sunava gets to  
> see the server-side part!)

Looks like one of your tests with all those nasty tabs :-)


>> http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/001.htm
>
> Hm.. This passes in some browsers for me. It fails in Firefox (and  
> correctly outputs failed). It passes in Opera and IE7. I can't even  
> figure out why it fails in Safari - it doesn't send the request..

Hmm.


>> http://tc.labs.opera.com/apis/XMLHttpRequest/complex/001.htm
>
> This tests stuff nobody AFAIK has implemented yet like constants:
>
>   if(this.readyState == this.DONE && this.readyState ==  
> XMLHttpRequest.DONE)
>
> and DOM2Events support:
>
> client.addEventListener("readystatechange", function() {  
> if(this.readyState == this.DONE) log.push(3) }, false)
>
> This test is much too big and should be split into manageable chunks.

It was called "complex" for a reason. :-)


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Monday, 25 February 2008 14:51:42 UTC