Re: Potential bugs identified in XHR LC Test Suite

To add to the list:

http://tc.labs.opera.com/apis/XMLHttpRequest/open/028.php
http://tc.labs.opera.com/apis/XMLHttpRequest/statusText/001.htm
- expects exceptions to be thrown when the spec has been updated to return null/""

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/023.php
http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/024.php
http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/032.php
http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/033.php
http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/034.php
http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/035.php
http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/036.php
http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/037.php
- test assumes bad value will be ignored instead of throwing

I also had a question about the complex/001.htm test case. This test case seems to imply that readystatechange listeners are ordered. However, this is not specified in the XHR spec. The DOM Events spec explicitly says that listeners may be triggered in any order. It seems that all major browsers do actually keep the listeners ordered, and I've run across at least one webpage that relies on this behavior, but I don't think it's good form for a W3C test to be relying on it.

Cheers,
kats

Received on Saturday, 7 June 2008 16:32:38 UTC