[Webkit-unassigned] [Bug 14431] New: readyState 3 & responseText buffer issues

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jun 27 08:01:11 PDT 2007


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

           Summary: readyState 3 & responseText buffer issues
           Product: WebKit
           Version: 522+ (nightly)
          Platform: All
               URL: http://www.synchroedit.com/pt/
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: kalle.alm at gmail.com
                CC: ChristopherA at iPhoneWebDev.com


Safari 3 does not seem to handle the updating of the responseText buffer during
readyState 3 (interactive/loading) of XMLHttpRequests appropriately. The
expected behavior is that whenever the server sends/flushes output to the
client (browser), the client sets readyState to 3 (if not already), updates the
responseText buffer, and triggers a readystatechange. 

Safari seems to only set readyState to 3 once (when loading begins and
responseText is an empty string) and then nothing until the loading finishes
(readyState -> 4). During tests, we discovered that by "priming" the connection
as described by M. Stachowiak below, Safari for Mac OS X seemed to get it some
times, but not all. By increasing the "garbage" from 256 to 512 bytes, this
solution might work all the time, but this solution isn't exactly ideal. 

In email discussion, Geoffry Garen confirmed that Safari 3 does indeed issue a
ready state change of 3 every time it receives data, and that responseText IS
updated every time, which indicates the above behavior is a bug.

We have additionally tried two workarounds, as proposed by Maciej Stachowiak,
namely:
1) "prime" the connection with 256 bytes sent before any of the real data.
2) Use a MIME type that won't be subject to sniffing (I think "application/xml"
as opposed to "text/xml" may fit the bill). 

>From our tests, it would appear that neither of the above tests seem to do the
trick on our example code. 

Demo URLs:
- http://www.synchroedit.com/pt/ (perl test -- clean)
- http://www.synchroedit.com/pf1/ (perl fixes 1+2 above)
- http://www.synchroedit.com/pf2/ (perl fix 2 only)

Source code URLs:
- http://www.synchroedit.com/pt/perl-test.tar.gz
- http://www.synchroedit.com/pf1/perl-fix-1.tar.gz
- http://www.synchroedit.com/pf2/perl-fix-2.tar.gz


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



More information about the webkit-unassigned mailing list