Bug 9113 - REGRESSION (14581): XMLHttpRequest never calls onreadystatechange with a readystate == 4
Summary: REGRESSION (14581): XMLHttpRequest never calls onreadystatechange with a read...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: XML (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: Geoffrey Garen
URL:
Keywords: Regression
Depends on:
Blocks: 8370
  Show dependency treegraph
 
Reported: 2006-05-25 11:08 PDT by David Phillip Oster
Modified: 2006-06-02 10:30 PDT (History)
4 users (show)

See Also:


Attachments
Undo the XMLHttpRequest change from r14569 (736 bytes, patch)
2006-06-01 12:24 PDT, mitz
no flags Details | Formatted Diff | Diff
Mitz's patch w/changelog and layout test (4.84 KB, patch)
2006-06-01 14:45 PDT, Geoffrey Garen
ggaren: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Phillip Oster 2006-05-25 11:08:58 PDT
Regression: 14581 XMLHttpRequest never calls onreadystatechange with a readystate == 4

When I make a POST XMLHttpRequest, my handler, assigned to onreadystatechange is never called with readystate == 4 /* 4 means "loaded" */

14555 performed correctly.
Comment 1 David Phillip Oster 2006-05-25 11:28:00 PDT
One place to see this bug: http://google.com/calendar   Note the red box with the white text "Loading..." at the upper right of the page never goes away, only in this version of webKit.
Comment 2 David Phillip Oster 2006-06-01 10:05:54 PDT
The bug always happens trying to load the main window of Google Calendar. My callback gets called with state==1, then never gets called again.

The bug doesn't happen using the simple example on http://developer.apple.com/internet/webcontent/xmlhttpreq.html. (Uses 'GET')

The bug doesn't happen using a custom cgi I wrote, which uses POST, and issues two requests operating in parallel (modeling what Google Calendar is doing). (I've also tried it with just a single outstanding request.)
Comment 3 David Phillip Oster 2006-06-01 11:46:59 PDT
My guess is it needs to have a server that sends a redirect. Still trying to track it down.
Comment 4 mitz 2006-06-01 12:13:30 PDT
The regression happened between r14566 and r14569, probably in r14569 (fix <rdar://problem/4557926>) due to the following:
        Also removed XMLHttpRequest from the DOM object cache because XMLHttpRequest
        objects aren't accessed through the DOM.
Comment 5 mitz 2006-06-01 12:24:05 PDT
Created attachment 8649 [details]
Undo the XMLHttpRequest change from r14569

Undoing the XMLHttpRequest part of r14569 fixes the regression, but I have no understanding of the DOM object cache.
Comment 6 David Phillip Oster 2006-06-01 12:45:14 PDT
Thank you! It looks like, in my case, where the server redirects, that XMLHttpRequest->m_doc->m_view->m_frame becomes nil, sometime between the request's send() has been called. The fix you made possibly keeps the frame from being improperly garbage collected.
Comment 7 David Kilzer (:ddkilzer) 2006-06-01 13:24:37 PDT
(In reply to comment #3)
> My guess is it needs to have a server that sends a redirect. Still trying to
> track it down.

Note that the LayoutTests now support "http" tests that run as CGI scripts on an Apache web server, so it should be possible to write a test case for this.

I think it's safe to confirm this bug now, too.
Comment 8 Geoffrey Garen 2006-06-01 14:45:07 PDT
Created attachment 8652 [details]
Mitz's patch w/changelog and layout test

Uploading for posterity.
Comment 9 Geoffrey Garen 2006-06-01 14:47:23 PDT
Committed revision 14671.
Comment 10 David Phillip Oster 2006-06-02 10:30:49 PDT
Verified. This fixes my problem with Google Calendar. Thanks guys!