<Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

<Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Sunava Dutta

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

 

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/034.php

http://tc.labs.opera.com/apis/XMLHttpRequest/setRequestHeader/035.php

Server-side PHP seems to be causing the test to pass or fail and we can’t determine the PASS criteria. May we get a pointer to the source here? (I think this was given a long time before but I can’t seem to dig it up!)

 

 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).

 

Thanks!

 

 

 

--
Sunava Dutta
Program Manager (AJAX) - Developer Experience Team, Internet Explorer

One Microsoft Way, Redmond WA 98052
TEL# (425) 705-1418

FAX# (425) 936-7329

 

Reply | Threaded
Open this post in threaded view
|

Re: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Ian Hickson

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.   `._.-(,_..'--(,_..'`-.;.'
Reply | Threaded
Open this post in threaded view
|

Re: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Jonas Sicking-2
In reply to this post by Sunava Dutta

> _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

Reply | Threaded
Open this post in threaded view
|

RE: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Zhenbin Xu

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:[hidden email]]
Sent: Thursday, June 12, 2008 11:20 AM
To: Sunava Dutta
Cc: Web API public; IE8 Core AJAX SWAT Team; [hidden email]
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



Reply | Threaded
Open this post in threaded view
|

RE: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Zhenbin Xu
In reply to this post by Ian Hickson
Inline...

-----Original Message-----
From: Ian Hickson [mailto:[hidden email]]
Sent: Wednesday, June 11, 2008 9:34 PM
To: Sunava Dutta
Cc: Web API public; IE8 Core AJAX SWAT Team; [hidden email]
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.   `._.-(,_..'--(,_..'`-.;.'
Reply | Threaded
Open this post in threaded view
|

RE: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Ian Hickson
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.   `._.-(,_..'--(,_..'`-.;.'
 
Reply | Threaded
Open this post in threaded view
|

Re: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Jonas Sicking-2
In reply to this post by Zhenbin Xu

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


Reply | Threaded
Open this post in threaded view
|

RE: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Zhenbin Xu
In reply to this post by Ian Hickson
Inline...

> -----Original Message-----
> From: Ian Hickson [mailto:[hidden email]]
> Sent: Sunday, June 15, 2008 11:46 PM
> To: Zhenbin Xu
> Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
> [hidden email]
> 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]  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 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. XMLHTTP
has proven to be extremely valuable for the past years without providing DOM
level 3 support or equivalent DOM support between UA and responseXML.



> --
> Ian Hickson               U+1047E                )\._.,--....,'``.
> fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-
> .;.'
Reply | Threaded
Open this post in threaded view
|

RE: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Zhenbin Xu
In reply to this post by Jonas Sicking-2

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:[hidden email]]
> Sent: Monday, June 16, 2008 2:13 PM
> To: Zhenbin Xu
> Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
> [hidden email]
> 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
>


Reply | Threaded
Open this post in threaded view
|

RE: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Ian Hickson
In reply to this post by Zhenbin Xu

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

Reply | Threaded
Open this post in threaded view
|

Re: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Jonas Sicking-2

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

Reply | Threaded
Open this post in threaded view
|

RE: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Zhenbin Xu
In reply to this post by Ian Hickson

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:[hidden email]]
> Sent: Tuesday, June 17, 2008 1:51 AM
> To: Zhenbin Xu
> Cc: Sunava Dutta; Web API public; IE8 Core AJAX SWAT Team; public-
> [hidden email]
> 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 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.   `._.-(,_..'--(,_..'`-
> .;.'


Reply | Threaded
Open this post in threaded view
|

RE: <Further LC Followup from IE> RE: Potential bugs identified in XHR LC Test Suite

Ian Hickson

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