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
