[webkit-dev] XMLHttpRequest and readyState==3

[Christopher Allen]

Finally got a chance to test this for this Safari bug to see if it
also exists on the iPhone, and to my surprise it is working perfectly
there, almost exactly like Firefox:

Firefox 2.0.0.4:

    run_test()...
    Opening request to poller.cgi (POST; asynchronous)
    Setting onreadystatechange handler
    Sending request
    State change: 0 => 1
    Request was sent.
    State change: 1 => 2
    State change: 2 => 3
    Input: I am now 0 out of 10.
    State change: 3 => 3
    Input: I am now 1 out of 10.
    State change: 3 => 3
    Input: I am now 2 out of 10.
    State change: 3 => 3
    Input: I am now 3 out of 10.
    State change: 3 => 3
    Input: I am now 4 out of 10.
    State change: 3 => 3
    Input: I am now 5 out of 10.
    State change: 3 => 3
    Input: I am now 6 out of 10.
    State change: 3 => 3
    Input: I am now 7 out of 10.
    State change: 3 => 3
    Input: I am now 8 out of 10.
    State change: 3 => 3
    Input: I am now 9 out of 10.
    State change: 3 => 3
    Input: I am now 10 out of 10.
    State change: 3 => 4

iPhone 1.0 (:

    run_test()...
    Opening request to poller.cgi (POST; asynchronous)
    Setting onreadystatechange handler
    Sending request
    Request was sent
    State change: 0 => 2
    State change: 2 => 3
    Input: I am now 0 out of 10.
    State change: 3 => 3
    Input: I am now 1 out of 10.
    State change: 3 => 3
    Input: I am now 2 out of 10.
    State change: 3 => 3
    Input: I am now 3 out of 10.
    State change: 3 => 3
    Input: I am now 4 out of 10.
    State change: 3 => 3
    Input: I am now 5 out of 10.
    State change: 3 => 3
    Input: I am now 6 out of 10.
    State change: 3 => 3
    Input: I am now 7 out of 10.
    State change: 3 => 3
    Input: I am now 8 out of 10.
    State change: 3 => 3
    Input: I am now 9 out of 10.
    State change: 3 => 3
    Input: I am now 10 out of 10.
    State change: 3 => 4

I'm not sure why the trivial difference in the beginning, but we are
quite pleased that even if this doesn't work on the desktop quite
right, that it does work correctly on the iPhone.

I'll have Kalle update the both bug reports:
http://bugs.webkit.org/show_bug.cgi?id=14431 and Apple RADAR Problem
ID is 5298296.

Onward to some sophisticated iPhone AJAX webapps ;-)

-- Christopher Allen


For those of you interested, here is the history:

On 6/25/07, Christopher Allen <ChristopherA at iphonewebdev.com> wrote:
> We are in the process of trying to make SynchroEdit
> <www.synchroedit.com> work with Safari 3.0, with the eventual goal of
> seeing if it is possible to synchroedit documents using an iPhone.
>
> SynchroEdit is an open-source simultaneous web editor (in the style of
> SubEthaEdit) that currently only works in Mozilla/Firefox/Camino
> browsers. The technique it uses is to synchronize the DOM tree between
> multiple machines, so it potentially has some interesting uses beyond
> synchronous editing.
>
> For the most part, things seem to be working well, but one feature we
> make use of heavily is the readyState==3 effect which is supported by
> Firefox. We have read that this feature is unsupported by the WHATWG
> spec, and that it will most likely not be implemented into Safari.
>
> The reason why we need this functionality is that we are building
> highly-interactive web applications, and we have found that we need to
> cut down on the number of connections to and from the HTTP server, in
> order to gain performance. Opening a new connection for every
> input/output request would slow the browser, and the server, down
> substantially. As the browser is the initiator of all requests,
> pending output (from server to client) requests can only be determined
> by repeatedly polling the server for updates, or by keeping some form
> of streaming connection using a technique like the readystate
> technique as described below.
>
> Basically, the Firefox technique involves reading the
> <XMLHttpRequest>.responseText value while the request itself stays in
> readyState==3 (loading). The responseText buffer updates as new input
> appears, and in this manner a "streaming data connection" is achieved.
>
> Whenever new data is sent to the browser from the server via the
> XMLHttpRequest, Firefox triggers another "readystatechange", even
> though the readyState changes "from 3 to 3". This lets coders put in
> code akin to "onRead" for a regular TCP connection interface, but in
> AJAX apps. This technique has been hugely effective not only for
> SynchroEdit, but for other applications that keep a continuous
> connection to the server such as interactive chat applications.

On 6/25/07, Geoffrey Garen <ggaren at apple.com> wrote:
> > For the most part, things seem to be working well, but one feature we
> > make use of heavily is the readyState==3 effect which is supported by
> > Firefox. We have read that this feature is unsupported by the WHATWG
> > spec, and that it will most likely not be implemented into Safari.
>
> Where did you hear that? From code inspection, I see that
> XMLHttpRequest issues a "ready state change" of 3 every time it
> receives data. Can you point me to the relevant part of the WHATWG spec?
>
> > It appears WebKit is not setting the
> > responseText variable until the request has completed. Is there a way
> > to access this text prior to state 4?
>
>  From code inspection, I see that XMLHttpRequest updates responseText
> every time it receives data.
>
> Perhaps you're seeing the results of slightly different networking
> implementations. For example, you might need to send data in larger
> chunks in order to convince the networking layer to flush its data up
> to the application level.


On 6/26/07, Christopher Allen <ChristopherA at iphonewebdev.com> wrote:
> We've written up a simple example using perl cgi and js/xhr to
> demonstrate this problem. In Firefox, the expected behavior appears.
> Every second, a new line appears counting up from 1 to 10. In Safari,
> there's a 10 second delay with nothing, and then 10 lines appear
> counting up from 1 to 10 all at once, just as the readyState goes from
> 3 to 4. We never see readyState going from 3 to 3 as we do with
> Firefox.
>
> URL demonstrating this behavior: http://www.synchroedit.com/pt/
>
> URL with source code for this test:
> http://www.synchroedit.com/pt/perl-test.tar.gz
>
> The perl cgi script has autoflushing enabled, which means the buffer
> is flushed for every newline. In Firefox, the responseText is updated
> whenever the perl side sends and flushes data, while Safari's
> responseText stays empty until the perl cgi closes the connection and
> the request enters readyState 4.

On 6/26/07, Geoffrey Garen <ggaren at apple.com> wrote:
> > Is this capability supposed to be to in Safari, thus our test above
> > demonstrates a bug?
>
> At first glance, this seems like a bug. I think the best way to proceed is
> to get your data into a bug report @ bugs.webkit.org.

On 6/27/07, Kalle Alm <kalle.alm at gmail.com> wrote:
> Sorry for spamming the list, but thought I'd add that I've filed this as
> a bug here: http://bugs.webkit.org/show_bug.cgi?id=14431

On 6/27/07, Kalle Alm alm at gmail.com> wrote:
> Filed Apple bug as well -- the URL looks weird, but maybe it works.
> Problem ID is 5298296; URL which may or may not work is:
> https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/1/wo/P1gr2UkN22B8VVelCsmWn0/4.22