RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
It seems we are in agreement, mostly :-)
The point of a fictional browser is that it has no market share, no application
built on top of it and thus would not cause customer pain when it changes
implementation.
In the case there isn't clear technical differences, I don't think we should
pick
the right solution based on implementer's cost. Rather We should base it on
customer impact.
A bank with 6000 applications built on top of IE's current APIs simply would
not be happy
if some applications cannot run due to changes in some underlying object model.
And this is not IE's problem alone since the bank simply cannot upgrade or
change the browser,
if all other browsers result in the same breakage.
-Original Message-
From: Ian Hickson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2008 1:51 AM
To: Zhenbin Xu
Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
[EMAIL PROTECTED]
Subject: RE: Further LC Followup from IE RE: Potential bugs
identified in XHR LC Test Suite
On Tue, 17 Jun 2008, Zhenbin Xu wrote:
I am not sure if I understand your question.
responseXML.parseError
has the error information
http://msdn.microsoft.com/en-us/library/aa926483.aspx
Oh, I assumed Sunava meant a conforming Document object was
returned.
A parseError-type object would be what I had in mind, yes. However,
if
we do this, then we should specify it. If we don't specify it, I'd
rather have an exception.
The spec can simply state that a conforming document object is
returned,
which includes out-of-band error information. This is what IE does
today
and is a very reasonable approach that allows rich error information
for
debugging.
I don't believe it is conforming for Document objects to have
parseError
attributes, but I could be mistaken -- is there a spec for parseError?
Even if there isn't, though, I agree that it is a generally good
solution
to the problem, I'm just saying that we should specify it, so that UAs
can be standards-compliant and support it interoperably.
Not really; if the script is expecting an exception, and receives
null
instead, then they'll just get an exception as soon as they
dereference the object, which in almost all cases will be straight
away.
[Zhenbin] I should explain the scenario I talked about. For instance,
if
I am to write a wrapper object myXHR, it makes a difference for me
when
I do the following
myXHR.responseXML
if (!_innerResponseXML)
{
try
{
_innerResponseXML = _innerXHR.responseXML;
}
catch (e)
{
_myexception = e;
return _dummpyResponseXML;
}
}
return _innerResponseXML;
My try catch would not catch null. And the exception would be passed
on
to my callers, which is not what I wanted.
Indeed.
If we are going to spec it to accommodate all existing browsers,
we
would want to make it return null or INVALID_STATE_ERR
exception.
We want interoperable behaviour, so defining it in this way would
be a
bad idea. (I don't really have an opinion either way about
exception
vs null, but it seems that we should just pick whatever is most
commonly implemented, which I'm guessing is what Anne did here.)
Fair enough. So let's pick one.
What is commonly implemented? Is it largest browser market share?
Since the cost to implementations for fixing the problem is independent
of
the size of the user base, it would be based just on the number of
independent implementations.
Is it number of enterprise applications written on top of particular
browser?
All the browsers want to be compatible with the Web, so if there are
mroe
Web sites depending on the exception behaviour than the null behaviour,
then we clearly should do the exception behaviour. And vice versa. Do
we
have any good numbers on this? (That there are widely deployed browsers
that return null instead of throwing an exception tends to suggest that
Web pages don't depend on either behaviour; we'd probably need evidence
to the contrary to decide one way or the other based on compatibility.)
Is it the number of browers, in which case I hope my fictional
home grown personal browser gets a vote :-)
Obviously fictional browsers aren't relevant, since the cost of fixing
a
fictional browser is zero.
From a pure technical point of view, predictably throw exception on
state violations is easier to understand. I hope you would agree
there
is value to change spec for the sake of consistent programming model
(which happens to be the IE model).
Indeed.
Did the spec call out that responseXML returned from XHR should have
equivalent DOM support as UA's object? If it is, that would be a
good
topic for us to debate about.
I believe the spec just says
RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
On Wed, 18 Jun 2008, Zhenbin Xu wrote: In the case there isn't clear technical differences, I don't think we should pick the right solution based on implementer's cost. Rather We should base it on customer impact. A bank with 6000 applications built on top of IE's current APIs simply would not be happy if some applications cannot run due to changes in some underlying object model. And this is not IE's problem alone since the bank simply cannot upgrade or change the browser, if all other browsers result in the same breakage. For non-Web HTML pages like in this example, solutions like IE's IE7 mode are fine. IMHO we should be concentrating on pages on the Web, not on browser-specific pages -- interoperability isn't relevant when the page isn't intended to run on multiple browsers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
Inline...
-Original Message-
From: Ian Hickson [mailto:[EMAIL PROTECTED]
Sent: Sunday, June 15, 2008 11:46 PM
To: Zhenbin Xu
Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
[EMAIL PROTECTED]
Subject: RE: Further LC Followup from IE RE: Potential bugs
identified in XHR LC Test Suite
On Sun, 15 Jun 2008, Zhenbin Xu wrote:
Ian wrote:
On Wed, 11 Jun 2008, Sunava Dutta wrote:
When Parsing Error happens, IE would still retain responseXML and
put error information on the object. Isnt this better than null
as
there�s more relevant information for the web developer?
How does one distinguish a document returned with parse error
information from one that happens to look like a parse error but
was
well-formed?
I wouldn't mind including more information but it seems like it
should
be out-of-band.
I am not sure if I understand your question. responseXML.parseError
has
the error information
http://msdn.microsoft.com/en-us/library/aa926483.aspx
Oh, I assumed Sunava meant a conforming Document object was returned. A
parseError-type object would be what I had in mind, yes. However, if we
do
this, then we should specify it. If we don't specify it, I'd rather
have
an exception.
[Zhenbin] The spec can simply state that a conforming document object
is returned, which includes out-of-band error information. This is what
IE does today and is a very reasonable approach that allows rich error
information for debugging.
The test is expecting us to return NULL in case open() has not
been
called. We throw an exception in IE. I�d pre fer if the spec
says �MUST return null OR an exception� otherwise I fear sites
today will be broken.
If a site is expecting an exception and gets null, then they'll get
an
exception when they try to dereferene the null, so in most cases it
seems like this would work anyway.
Properly written sites would have no problem one way or the other.
However if someone is writing a wrapper on top of XMLHTTP, clearly it
would make a difference on how to expose wrapped properties.
Not really; if the script is expecting an exception, and receives null
instead, then they'll just get an exception as soon as they dereference
the object, which in almost all cases will be straight away.
[Zhenbin] I should explain the scenario I talked about. For instance, if
I am to write a wrapper object myXHR, it makes a difference for me when I
do the following
myXHR.responseXML
if (!_innerResponseXML)
{
try
{
_innerResponseXML = _innerXHR.responseXML;
}
catch (e)
{
_myexception = e;
return _dummpyResponseXML;
}
}
return _innerResponseXML;
My try catch would not catch null. And the exception would be passed on
to my callers, which is not what I wanted.
If we are going to spec it to accommodate all existing browsers, we
would want to make it return null or INVALID_STATE_ERR exception.
We want interoperable behaviour, so defining it in this way would be a
bad
idea. (I don't really have an opinion either way about exception vs
null,
but it seems that we should just pick whatever is most commonly
implemented, which I'm guessing is what Anne did here.)
[Zhenbin] Fair enough. So let's pick one.
What is commonly implemented? Is it largest browser market share?
Is it number of enterprise applications written on top of particular browser?
Is it the number of browers, in which case I hope my fictional home grown
personal browser gets a vote :-)
From a pure technical point of view, predictably throw exception on state
violations is easier to understand. I hope you would agree there
is value to change spec for the sake of consistent programming model (which
happens to be the IE model).
I think it's important that we test that the DOM returned from XHR
is
DOM Core conformant just like any other, so this seems like an
important and relevant testing area for XHR.
That is not necessarily a good idea because you would then have to
mandate which level of DOM Core support is required. And if the spec
requires DOM level 3, that is big barrier for new user agent that
wants
to be compliant with XHR spec.
getElementById requires DOM Level 2. At the least the testing case
can
be changed to use getElementByTagName, which is DOM level 1.
I think expecting DOM Level 3 is the least of our worries -- after all,
that's a 3+ year old spec. So testing just DOM Level 2 is really not a
problem as far as I can tell. However, I agree that it would make sense
to
make the test pass if the UA didn't support that level of DOM on
regular
DOM objects too. The key is just to make sure that the objects returned
by
XHR are of equivalent DOM support as the rest of the UA's objects.
[Zhenbin
RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
Exceptional situation in general doesn't hinder interoperability. It only becomes an issue if it is clearly stated in W3C spec and used as a way to measure if UA is compliant. We have provided our feedback to write spec in a away all current browsers are complaint. If the general sentiment is to pick one model, then lets pick the exception model, which is the model original XHR inventors picked. Technically because all other XHR methods/properties throw exceptions in case of state violation, exception for responseXML/responseText is better. If original XHR picked the null model, then we should go null model. The important thing really is consistency, thus predictability. Thanks! Zhenbin -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Monday, June 16, 2008 2:13 PM To: Zhenbin Xu Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public- [EMAIL PROTECTED] Subject: Re: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite Zhenbin Xu wrote: The issue of return null or an exception is simply a compromise here. IE would throw an exception for state violations. Accessing responseXML before open() is a state violation so it would trigger exception. Other browsers may return null in such situation. In order to accommodate all browsers, the spec would have to be rewritten in some way. Please note that it is not a goal for the spec to be written in such a way that all existing browsers are conforming to the spec. It turned out that it was impossible to write a spec with that goal while still keeping the spec useful. So we no longer try to accomodate all browsers, but instead write a spec that leads to interoperability between browsers. We would certainly love to have the spec change to MUST throw INVALID_STATE_ERR exception, which is consistent with other INVALID_STATE_ERR cases. For instance, the spec says if send() is called before OPENED, it should trigger INVALID_STATE_ERR exception. Another example is that user agent must raise INVALID_STATE_ERR if status is not available. responseText and responseXML are the outlier in the spec. Personally I think it makes more sense to return 'null' from .responseXML. We at mozilla have not had any interoperability problems with this behavior. Exceptions are better left for exceptional circumstances. However I can't say that I think the behavior is very important to me one way or another, as long as it's usefully defined. Best Regards, Jonas Sicking
RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
On Tue, 17 Jun 2008, Zhenbin Xu wrote:
I am not sure if I understand your question. responseXML.parseError
has the error information
http://msdn.microsoft.com/en-us/library/aa926483.aspx
Oh, I assumed Sunava meant a conforming Document object was returned.
A parseError-type object would be what I had in mind, yes. However, if
we do this, then we should specify it. If we don't specify it, I'd
rather have an exception.
The spec can simply state that a conforming document object is returned,
which includes out-of-band error information. This is what IE does today
and is a very reasonable approach that allows rich error information for
debugging.
I don't believe it is conforming for Document objects to have parseError
attributes, but I could be mistaken -- is there a spec for parseError?
Even if there isn't, though, I agree that it is a generally good solution
to the problem, I'm just saying that we should specify it, so that UAs
can be standards-compliant and support it interoperably.
Not really; if the script is expecting an exception, and receives null
instead, then they'll just get an exception as soon as they
dereference the object, which in almost all cases will be straight
away.
[Zhenbin] I should explain the scenario I talked about. For instance, if
I am to write a wrapper object myXHR, it makes a difference for me when
I do the following
myXHR.responseXML
if (!_innerResponseXML)
{
try
{
_innerResponseXML = _innerXHR.responseXML;
}
catch (e)
{
_myexception = e;
return _dummpyResponseXML;
}
}
return _innerResponseXML;
My try catch would not catch null. And the exception would be passed on
to my callers, which is not what I wanted.
Indeed.
If we are going to spec it to accommodate all existing browsers, we
would want to make it return null or INVALID_STATE_ERR exception.
We want interoperable behaviour, so defining it in this way would be a
bad idea. (I don't really have an opinion either way about exception
vs null, but it seems that we should just pick whatever is most
commonly implemented, which I'm guessing is what Anne did here.)
Fair enough. So let's pick one.
What is commonly implemented? Is it largest browser market share?
Since the cost to implementations for fixing the problem is independent of
the size of the user base, it would be based just on the number of
independent implementations.
Is it number of enterprise applications written on top of particular
browser?
All the browsers want to be compatible with the Web, so if there are mroe
Web sites depending on the exception behaviour than the null behaviour,
then we clearly should do the exception behaviour. And vice versa. Do we
have any good numbers on this? (That there are widely deployed browsers
that return null instead of throwing an exception tends to suggest that
Web pages don't depend on either behaviour; we'd probably need evidence
to the contrary to decide one way or the other based on compatibility.)
Is it the number of browers, in which case I hope my fictional
home grown personal browser gets a vote :-)
Obviously fictional browsers aren't relevant, since the cost of fixing a
fictional browser is zero.
From a pure technical point of view, predictably throw exception on
state violations is easier to understand. I hope you would agree there
is value to change spec for the sake of consistent programming model
(which happens to be the IE model).
Indeed.
Did the spec call out that responseXML returned from XHR should have
equivalent DOM support as UA's object? If it is, that would be a good
topic for us to debate about.
I believe the spec just says that you return a Document object; it is the
lack of a distinction between different Document objects that requires the
level of support to be the same. As you said, a consistent programming
model has value.
I disagree that because DOM Level 3 is 3+ yr old spec that every UA has
to support it in order to be XHR compliant, if that is what you implied.
I didn't mean to imply that. I don't think XHR should require any
particular level of support.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
Ian Hickson wrote: On Tue, 17 Jun 2008, Zhenbin Xu wrote: I am not sure if I understand your question. responseXML.parseError has the error information http://msdn.microsoft.com/en-us/library/aa926483.aspx Oh, I assumed Sunava meant a conforming Document object was returned. A parseError-type object would be what I had in mind, yes. However, if we do this, then we should specify it. If we don't specify it, I'd rather have an exception. The spec can simply state that a conforming document object is returned, which includes out-of-band error information. This is what IE does today and is a very reasonable approach that allows rich error information for debugging. I don't believe it is conforming for Document objects to have parseError attributes, but I could be mistaken -- is there a spec for parseError? Even if there isn't, though, I agree that it is a generally good solution to the problem, I'm just saying that we should specify it, so that UAs can be standards-compliant and support it interoperably. I think we have two choices for how to handle parse errors here: 1. Mandate that a Document object containing a .parseError property is returned for .responseXML 2. Mandate that null is returned I think some hodgepodge solution of the two is likely just going to be harder to code against for developers. Are we comfortable adding the .parseError object to the XHR spec? Feels like spec creep to me unfortunately. / Jonas
RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
On Sun, 15 Jun 2008, Zhenbin Xu wrote: Ian wrote: On Wed, 11 Jun 2008, Sunava Dutta wrote: When Parsing Error happens, IE would still retain responseXML and put error information on the object. Isnt this better than null as there�s more relevant information for the web developer? How does one distinguish a document returned with parse error information from one that happens to look like a parse error but was well-formed? I wouldn't mind including more information but it seems like it should be out-of-band. I am not sure if I understand your question. responseXML.parseError has the error information http://msdn.microsoft.com/en-us/library/aa926483.aspx Oh, I assumed Sunava meant a conforming Document object was returned. A parseError-type object would be what I had in mind, yes. However, if we do this, then we should specify it. If we don't specify it, I'd rather have an exception. The test is expecting us to return NULL in case open() has not been called. We throw an exception in IE. I�d pre fer if the spec says �MUST return null OR an exception� otherwise I fear sites today will be broken. If a site is expecting an exception and gets null, then they'll get an exception when they try to dereferene the null, so in most cases it seems like this would work anyway. Properly written sites would have no problem one way or the other. However if someone is writing a wrapper on top of XMLHTTP, clearly it would make a difference on how to expose wrapped properties. Not really; if the script is expecting an exception, and receives null instead, then they'll just get an exception as soon as they dereference the object, which in almost all cases will be straight away. If we are going to spec it to accommodate all existing browsers, we would want to make it return null or INVALID_STATE_ERR exception. We want interoperable behaviour, so defining it in this way would be a bad idea. (I don't really have an opinion either way about exception vs null, but it seems that we should just pick whatever is most commonly implemented, which I'm guessing is what Anne did here.) I think it's important that we test that the DOM returned from XHR is DOM Core conformant just like any other, so this seems like an important and relevant testing area for XHR. That is not necessarily a good idea because you would then have to mandate which level of DOM Core support is required. And if the spec requires DOM level 3, that is big barrier for new user agent that wants to be compliant with XHR spec. getElementById requires DOM Level 2. At the least the testing case can be changed to use getElementByTagName, which is DOM level 1. I think expecting DOM Level 3 is the least of our worries -- after all, that's a 3+ year old spec. So testing just DOM Level 2 is really not a problem as far as I can tell. However, I agree that it would make sense to make the test pass if the UA didn't support that level of DOM on regular DOM objects too. The key is just to make sure that the objects returned by XHR are of equivalent DOM support as the rest of the UA's objects. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
Inline... -Original Message- From: Ian Hickson [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 11, 2008 9:34 PM To: Sunava Dutta Cc: Web API public; IE8 Core AJAX SWAT Team; [EMAIL PROTECTED] Subject: Re: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite Some quick comments on some of the comments regarding the tests: On Wed, 11 Jun 2008, Sunava Dutta wrote: http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm When Parsing Error happens, IE would still retain responseXML and put error information on the object. Isnt this better than null as there�s more relevant information for the web developer? How does one distinguish a document returned with parse error information from one that happens to look like a parse error but was well-formed? I wouldn't mind including more information but it seems like it should be out-of-band. [Zhenbin] I am not sure if I understand your question. responseXML.parseError has the error information http://msdn.microsoft.com/en-us/library/aa926483.aspx http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm The test is expecting us to return NULL in case open() has not been called. We throw an exception in IE. I�d pre fer if the spec says �MUST return null OR an exception� otherwise I fear sites today will be broken. If a site is expecting an exception and gets null, then they'll get an exception when they try to dereferene the null, so in most cases it seems like this would work anyway. [Zhenbin] Properly written sites would have no problem one way or the other. However if someone is writing a wrapper on top of XMLHTTP, clearly it would make a difference on how to expose wrapped properties. OTOH they likely already have handled both cases (currently IE throws exceptions and others return null). If we are going to spec it to accommodate all existing browsers, we would want to make it return null or INVALID_STATE_ERR exception. If we are going to spec it the right way, then I think throw exception is a more consistent design (see my reply to Jonas). http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/012.htm http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/013.htm This test really doesn�t test XHR here. It seems to be focused on manipulating the XML DOM. (I also don�t think Microsoft.XMLDOM supports getElementById for an XML document FYI). Also, if I'm barking up the wrong tree here please let me know! I think it's important that we test that the DOM returned from XHR is DOM Core conformant just like any other, so this seems like an important and relevant testing area for XHR. [Zhenbin] That is not necessarily a good idea because you would then have to mandate which level of DOM Core support is required. And if the spec requires DOM level 3, that is big barrier for new user agent that wants to be compliant with XHR spec. getElementById requires DOM Level 2. At the least the testing case can be changed to use getElementByTagName, which is DOM level 1. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
The issue of return null or an exception is simply a compromise here. IE would throw an exception for state violations. Accessing responseXML before open() is a state violation so it would trigger exception. Other browsers may return null in such situation. In order to accommodate all browsers, the spec would have to be rewritten in some way. We would certainly love to have the spec change to MUST throw INVALID_STATE_ERR exception, which is consistent with other INVALID_STATE_ERR cases. For instance, the spec says if send() is called before OPENED, it should trigger INVALID_STATE_ERR exception. Another example is that user agent must raise INVALID_STATE_ERR if status is not available. responseText and responseXML are the outlier in the spec. Thanks! Zhenbin -Original Message- From: Jonas Sicking [mailto:[EMAIL PROTECTED] Sent: Thursday, June 12, 2008 11:20 AM To: Sunava Dutta Cc: Web API public; IE8 Core AJAX SWAT Team; [EMAIL PROTECTED] Subject: Re: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite _http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm_ The test is expecting us to return NULL in case open() has not been called. We throw an exception in IE. I'd pre fer if the spec says **MUST return null OR an exception** otherwise I fear sites today will be broken. How would that help sites that expect an exception, since it would still be conforming for the UA to return null? If anything, your proposal seems to make it harder for sites to code against the spec. / Jonas
Re: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
Zhenbin Xu wrote: The issue of return null or an exception is simply a compromise here. IE would throw an exception for state violations. Accessing responseXML before open() is a state violation so it would trigger exception. Other browsers may return null in such situation. In order to accommodate all browsers, the spec would have to be rewritten in some way. Please note that it is not a goal for the spec to be written in such a way that all existing browsers are conforming to the spec. It turned out that it was impossible to write a spec with that goal while still keeping the spec useful. So we no longer try to accomodate all browsers, but instead write a spec that leads to interoperability between browsers. We would certainly love to have the spec change to MUST throw INVALID_STATE_ERR exception, which is consistent with other INVALID_STATE_ERR cases. For instance, the spec says if send() is called before OPENED, it should trigger INVALID_STATE_ERR exception. Another example is that user agent must raise INVALID_STATE_ERR if status is not available. responseText and responseXML are the outlier in the spec. Personally I think it makes more sense to return 'null' from .responseXML. We at mozilla have not had any interoperability problems with this behavior. Exceptions are better left for exceptional circumstances. However I can't say that I think the behavior is very important to me one way or another, as long as it's usefully defined. Best Regards, Jonas Sicking
Re: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
_http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm_ The test is expecting us to return NULL in case open() has not been called. We throw an exception in IE. I’d pre fer if the spec says *“*MUST return null OR an exception*”* otherwise I fear sites today will be broken. How would that help sites that expect an exception, since it would still be conforming for the UA to return null? If anything, your proposal seems to make it harder for sites to code against the spec. / Jonas
Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
2nd email to the new alias from me! Dev, test and I ran a few more tests and had some results to share. A few of these should probably be clarified in the LC draft or the test cases should change. Details below... http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm When Parsing Error happens, IE would still retain responseXML and put error information on the object. Isnt this better than null as there’s more relevant information for the web developer? http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm The test is expecting us to return NULL in case open() has not been called. We throw an exception in IE. I’d pre fer if the spec says “MUST return null OR an exception” otherwise I fear sites today will be broken. http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/012.htm http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/013.htm This test really doesn’t test XHR here. It seems to be focused on manipulating the XML DOM. (I also don’t think Microsoft.XMLDOM supports getElementById for an XML document FYI). Also, if I'm barking up the wrong tree here please let me know! http://tc.labs.opera.com/apis/XMLHttpRequest/open/032.htm What's the purpose of this test case and which part of spec is it testing? It’s difficult to understand that. http://tc.labs.opera.com/apis/XMLHttpRequest/abort/003.htm The abort() method resets event listeners. I’m looking at the 4/15 spec (on W3C site) and was wondering where this is specified? http://tc.labs.opera.com/apis/XMLHttpRequest/onreadystatechange/004.htm We don't raise onreadystatechange events from within the onreadystatechange event handler as there's danger of recursion. FYI I can't find any guidance here in the spec. http://tc.labs.opera.com/apis/XMLHttpRequest/send/009.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/017.htm Another dependency on e.code (As mentioned in the previous round of feedback on these tests. We can’t actually run the test until this is removed. http://tc.labs.opera.com/apis/XMLHttpRequest/send/011.htm In this test send(1) doesn’t work. The reason being we don’t cast an argument to a string. This is also not defined in the spec. Thanks! From: Sunava Dutta Sent: Thursday, June 05, 2008 7:47 PM To: Web API public; IE8 Core AJAX SWAT Team Subject: Potential bugs identified in XHR LC Test Suite Thanks for writing these cases by LC exit. It really makes the process of providing feedback prior to CR a lot easier. I ran these (the tests below fail on Safari3 ,Firefox 3 and IE8) with my team and had a few questions. If these issues can be addressed we can give further feedback and recommendations on the results/implementations. (Let me know if I’m wrong on our test analysis!) The rest of the tests that fail (without issues in the test itself) are being investigated further by my team so expect more over the next few days as we dig in. http://tc.labs.opera.com/apis/XMLHttpRequest/open/033.htm This test seems to have a bug even though it passes. Line 24 uses top.opener.rr. The framework reports FAIL although the test passes. http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/001.htm http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/004.php http://tc.labs.opera.com/apis/XMLHttpRequest/getResponseHeader/001.htm http://tc.labs.opera.com/apis/XMLHttpRequest/getResponseHeader/007.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/013.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/014.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/015.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/016.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/001.htm http://tc.labs.opera.com/apis/XMLHttpRequest/readyState/002.htm These tests seem to be failing when the test autorun is used in IE. Running the tests individually causes them to pass on IE8. Looks like a bug in the test framework. http://tc.labs.opera.com/apis/XMLHttpRequest/getAllResponseHeaders/005.php This test fails because the network timeout is too short and passes sometimes (Unpredictable). http://tc.labs.opera.com/apis/XMLHttpRequest/send/005.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/007.htm http://tc.labs.opera.com/apis/XMLHttpRequest/send/008.htm This seems to be a minor test bug. The file we are receiving does not contain the string “PASS”, which is necessary for the test to pass. http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/010.htm http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/020.htm The exception object here is not directly supported by IE, causing us to fail here. Can the test be tweaked so we can test the XHR compliance here? Thanks! http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/021.htm The PHP page doesn’t seem to be producing valid content
Re: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
Some quick comments on some of the comments regarding the tests: On Wed, 11 Jun 2008, Sunava Dutta wrote: http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm When Parsing Error happens, IE would still retain responseXML and put error information on the object. Isnt this better than null as there�s more relevant information for the web developer? How does one distinguish a document returned with parse error information from one that happens to look like a parse error but was well-formed? I wouldn't mind including more information but it seems like it should be out-of-band. http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm The test is expecting us to return NULL in case open() has not been called. We throw an exception in IE. I�d pre fer if the spec says �MUST return null OR an exception� otherwise I fear sites today will be broken. If a site is expecting an exception and gets null, then they'll get an exception when they try to dereferene the null, so in most cases it seems like this would work anyway. http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/012.htm http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/013.htm This test really doesn�t test XHR here. It seems to be focused on manipulating the XML DOM. (I also don�t think Microsoft.XMLDOM supports getElementById for an XML document FYI). Also, if I'm barking up the wrong tree here please let me know! I think it's important that we test that the DOM returned from XHR is DOM Core conformant just like any other, so this seems like an important and relevant testing area for XHR. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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
Re: Potential bugs identified in XHR LC Test Suite
On Fri, 06 Jun 2008 04:47:31 +0200, Sunava Dutta [EMAIL PROTECTED] wrote: Meanwhile, I'd like to re-iterate a point I had raised up awhile back. Are the tests going to be 'complete' /comprehensive at CR in relation to the spec? MSFT obviously wants this test suite to be official ensuring that third parties do not write individual test cases undermining the credibility of the suite and demonstrating increased/decreased compliance post CR (when it's much harder to make changes). The test suite will be made complete (and official) during the CR period as per W3C policy. (And is required to be complete before we can exit CR.) -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
