Bug 33687

Summary: window.onload never fires if page contains a <script src=foo> whose load is cancelled by resource load delegate returning null from willSendRequest
Product: WebKit Reporter: Adam Roben (:aroben) <aroben>
Component: Page LoadingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: eric, xan.lopez
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
Patch hyatt: review+

Description Adam Roben (:aroben) 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".
Comment 1 Adam Roben (:aroben) 2010-01-14 14:08:31 PST
<rdar://problem/7543406>
Comment 2 Adam Roben (:aroben) 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.
Comment 3 Adam Roben (:aroben) 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.
Comment 4 Adam Roben (:aroben) 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?
Comment 5 Adam Roben (:aroben) 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.
Comment 6 Adam Roben (:aroben) 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>.
Comment 7 Adam Roben (:aroben) 2010-01-14 15:01:37 PST
Created attachment 46610 [details]
Patch
Comment 8 Adam Roben (:aroben) 2010-01-14 15:02:51 PST
I'll add the new test to LayoutTests/platform/qt/Skipped, too.
Comment 9 Dave Hyatt 2010-01-14 15:03:15 PST
Comment on attachment 46610 [details]
Patch

r=me
Comment 10 Adam Roben (:aroben) 2010-01-14 15:05:56 PST
Committed r53292: <http://trac.webkit.org/changeset/53292>
Comment 11 Eric Seidel (no email) 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
Comment 12 Eric Seidel (no email) 2010-01-14 17:14:19 PST
Adam?  Any thoughts on what we should do here for the Gtk bot?  Just skip this test?
Comment 13 Eric Seidel (no email) 2010-01-14 18:02:35 PST
Re-opening due to the bot failures.
Comment 14 Adam Roben (:aroben) 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.