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
<[EMAIL PROTECTED]> 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/>
