RESOLVED FIXED33687
window.onload never fires if page contains a <script src=foo> whose load is cancelled by resource load delegate returning null from willSendRequest
https://bugs.webkit.org/show_bug.cgi?id=33687
Summary window.onload never fires if page contains a <script src=foo> whose load is c...
Adam Roben (:aroben)
Reported 2010-01-14 14:08:00 PST
To reproduce: 1. Download the attached test case to LayoutTests/fast/loader 2. run-webkit-tests fast/loader/onload-willSendRequest-null-for-script.html The test will generate no output. It should generate output that includes the text "PASSED".
Attachments
Patch (5.23 KB, patch)
2010-01-14 15:01 PST, Adam Roben (:aroben)
hyatt: review+
Adam Roben (:aroben)
Comment 1 2010-01-14 14:08:31 PST
Adam Roben (:aroben)
Comment 2 2010-01-14 14:11:31 PST
The load of the script is initiated in HTMLTokenizer::scriptHandler with a call to DocLoader::requestScript. The load fails before requestScript returns, but requestScript returns a non-null CachedScript* anyway. HTMLTokenizer then never gets CachedResourceClient::notifyFinished for this script. I think the right fix might be for requestScript to return null in this case.
Adam Roben (:aroben)
Comment 3 2010-01-14 14:17:20 PST
Cache.cpp says <http://trac.webkit.org/browser/trunk/WebCore/loader/Cache.cpp?rev=53151#L134>: // We don't support immediate loads, but we do support immediate failure. But we're missing this particular "immediate failure" case.
Adam Roben (:aroben)
Comment 4 2010-01-14 14:21:35 PST
Cache::requestResource already returns null when the resource's load fails, but only if the cache is disabled. Maybe we should return null when the resource's load fails and the cache is enabled, too?
Adam Roben (:aroben)
Comment 5 2010-01-14 14:43:15 PST
(In reply to comment #4) > Cache::requestResource already returns null when the resource's load fails, but > only if the cache is disabled. Maybe we should return null when the resource's > load fails and the cache is enabled, too? I'm testing a fix that does just this. It fixes this bug, but I need to see if it causes any regression tests to fail.
Adam Roben (:aroben)
Comment 6 2010-01-14 14:45:40 PST
The current "immediate failure" code was added in r21732, for what it's worth: <http://trac.webkit.org/changeset/21732#file2>.
Adam Roben (:aroben)
Comment 7 2010-01-14 15:01:37 PST
Adam Roben (:aroben)
Comment 8 2010-01-14 15:02:51 PST
I'll add the new test to LayoutTests/platform/qt/Skipped, too.
Dave Hyatt
Comment 9 2010-01-14 15:03:15 PST
Comment on attachment 46610 [details] Patch r=me
Adam Roben (:aroben)
Comment 10 2010-01-14 15:05:56 PST
Eric Seidel (no email)
Comment 11 2010-01-14 16:26:05 PST
This looks like this broke the Gtk bots: http://build.webkit.org/results/GTK%20Linux%2032-bit%20Debug/r53294%20(2386)/fast/loader/onload-willSendRequest-null-for-script-diffs.txt --- layout-test-results/fast/loader/onload-willSendRequest-null-for-script-expected.txt 2010-01-14 15:35:03.995244189 -0800 +++ layout-test-results/fast/loader/onload-willSendRequest-null-for-script-actual.txt 2010-01-14 15:35:03.995244189 -0800 @@ -1,3 +1,4 @@ +CONSOLE MESSAGE: line 1: SyntaxError: Parse error Test for Bug 33687: window.onload never fires if page contains a <script src=foo> whose load is cancelled by resource load delegate returning null from willSendRequest. If the test passes, you should see the word "PASSED" below. PASSED
Eric Seidel (no email)
Comment 12 2010-01-14 17:14:19 PST
Adam? Any thoughts on what we should do here for the Gtk bot? Just skip this test?
Eric Seidel (no email)
Comment 13 2010-01-14 18:02:35 PST
Re-opening due to the bot failures.
Adam Roben (:aroben)
Comment 14 2010-01-15 07:46:14 PST
(In reply to comment #12) > Adam? Any thoughts on what we should do here for the Gtk bot? Just skip this > test? Yeah, I guess I was too hopeful about this "just working" on other platforms. The test was adde to GTK+'s Skipped file in r53286.
Note You need to log in before you can comment on or make changes to this bug.