[Webkit-unassigned] [Bug 13141] XMLHttpRequest should set readyState to 0 after abort()

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=13141


julien.chaffraix at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #16423|review?                     |
               Flag|                            |
  Attachment #16423|0                           |1
        is obsolete|                            |




------- Comment #4 from julien.chaffraix at gmail.com  2007-09-30 14:34 PDT -------
Created an attachment (id=16477)
 --> (http://bugs.webkit.org/attachment.cgi?id=16477&action=view)
Non recursive test case

> 1. I don't understand why you're removing the state change in open() I can see
> that affecting behavior (a second open call on a completed xhr?  what about a
> call which fails due to a domain check?)  Maybe I'm being over cautious, but if
> we're to remove that call, I think there should be a test to show that desired
> result.

The call to changeState is not necessary. The changeState is done in abort()
and not in open() now.
The instructions between the new call to changeReadyState and the old one are
related to the cancellation of the previous XMLHttpRequest (clearing document
and creating a new ResourceResponse()). They are thus unaffected by the change
and cannot return unexpectedly.
For the check, they were done after the call to changeState and it is also the
case with the patch.

> 2.  I'm not sure I fully understand your test case, and why it needs to be
> recursive as such.  Perhaps it's just to clever for me...

The aim is to try to abort the XMLHttpRequest for all the readyState. The
recursive is just a choice I have made. It implies an order in which we execute
the tests (from state 1 to 4).
I am not sure that this order is guaranteed in the test case attached which is
not recursive. Tell me which one should be the better (I would the output of
the previous one so that it is more understandable ;)) and I will create a new
patch.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.