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.   `._.-(,_..'--(,_..'`-.;.'