Re: XHR tests

On Sat, 09 Feb 2008 11:46:02 +0100, Charles McCathieNevile  
<> wrote:

> According to MS' testing 4 major browsers (I am guessing they mean  
> Opera, Safari, Mozilla/FF and IE although I am not actually sure) all  
> fail the following tests.


That test is half-fixed, well the TC bug is fixed. Neither Opera 9.5,  
Firefox 2, nor IE 7 pass though.

Opera 9.5 - returns a document but it's empty (document.documentElement is  
IE7 - like Opera
Firefox 2 - returns a <parsererror> document
Safari - passes test

There is a possible web content compatibility issue here if functions that  
expect documents may throw on null input. For example, does  
xsltprocessor.importStylesheet(null) throw? If it does the implementation  
we test for might break content that expects a broken document error to be  
handled differently.


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!


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


Fails cross-browser because of 4 different implementations of the order  
events should happen in on open() send() open()..


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 (!??)


Same results as 016.htm


Much like 012.htm. Tests first async open(), sync open() then send()

Opera 9.5 - fails because it leaves out two readyState "1" and one  
readyState "3" events
Firefox 2 - fails because it throws on second open
IE7 - fails because not all expected events are sent (even fewer than  
Safari - fails because it throws on send()


Reverse of 026: tests sync open(), async open(), send()

Opera 9.5 - doesn't send all expected events
Firefox 2 - doesn't send all expected events (unlikt 026 does not throw!)
IE7 - doesn't send all expected events
Safari - throws on send()


This is more a demo than a test. It tests creating an XHR instance from  
the XMLHttpRequest object of an about:blank window. It doesn't actually  
return a pass/fail condition, but Opera, IE and Safari agree on throwing  
an error. Firefox doesn't.


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.


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.


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.


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 (?!?)


Tests a specific sequence of method calls - open() async, send(), abort(),  
Fails in all browsers because not all expected events are sent (or they  
are sent in different order than expected)



Think all these tests are broken because  
doesn't do whatever it's supposed to. Anne?


This is not a test, it's a sort of demo or experiment, not entirely sure  
for what.


This support script is broken:

- all browsers tested actually pass these test.


Tests whether setRequestHeader throws if first argument is an empty string

Opera - doesn't throw, fails
Safari - doesn't throw, fails
IE - throws an exception but e.code is not what the script expects (it's  
Firefox - like IE

It seems OK to require that this is a DOMException and thus has .code  
defined, the risk of breaking existing content is pretty close to 0. The  
expected code is 12 for a SYNTAX_ERR.
BTW, the visual fail message when browser doesn't throw should be  
clarified. It's confusing to say "script did not run".


Same as 010 except it tests for first argument being undefined and IE  
doesn't actually throw here.


Tests calling setRequestHeader twice for Content-type. Expects a  
comma-concatenated string to be sent ('Content-type: first value, second  

Test is broken because  
is. If the support script had worked as expected, this would have been the  

Firefox - fail
IE - pass
Opera - fail
Safari - pass


Fails because print-header.script is broken


Tests both arguments to setRequestHeader being null. Same results as  


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


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


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.

Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
Opera - simply the best Internet experience

Received on Tuesday, 12 February 2008 01:37:00 UTC