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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]> 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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
