Bug 33349

Summary: http/tests/security/xss-DENIED-window-open-javascript-url.html timed out on Windows Debug Bot
Product: WebKit Reporter: Eric Seidel (no email) <eric>
Component: Tools / TestsAssignee: Adam Barth <abarth>
Status: RESOLVED WORKSFORME    
Severity: Normal CC: abarth, ap, aroben, bweinstein, commit-queue, dbates, ossy
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Bug Depends on:    
Bug Blocks: 32528    
Attachments:
Description Flags
Patch
none
Patch abarth: review-

Description Eric Seidel (no email) 2010-01-07 15:29:21 PST
http/tests/security/xss-DENIED-window-open-javascript-url.html timed out on Windows Debug Bot

Sigh.
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r52946%20(8254)/results.html

Added by abarth 3 weeks ago:
http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/security/xss-DENIED-window-open-javascript-url.html
Comment 1 Eric Seidel (no email) 2010-01-09 15:25:29 PST
Hit this again just now:
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53039%20(8329)/results.html
Comment 3 Eric Seidel (no email) 2010-01-09 15:31:51 PST
This seems to be the most common failure on the Windows Debug bot.

Earlier it was not occurring in "paired" failures, so the pairs I mention above are just coincidence.  This test failed in 6 of the last 15 runs.
Comment 4 Eric Seidel (no email) 2010-01-09 19:42:25 PST
Another failure:
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53047%20(8338)/results.html

I'll post a patch to skip this one on Monday if we don't have other theories.  Seems silly to keep the windows bot red like this.

Maybe Adam has an idea why this could be so flakey for windows?
Comment 5 Adam Barth 2010-01-09 23:38:23 PST
Created attachment 46229 [details]
Patch
Comment 6 Nikolas Zimmermann 2010-01-10 16:18:07 PST
Comment on attachment 46229 [details]
Patch

This just happened again: http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53054%20(8348)/results.html.
r+ to skip the test.
Comment 7 WebKit Commit Bot 2010-01-10 16:38:24 PST
Comment on attachment 46229 [details]
Patch

Clearing flags on attachment: 46229

Committed r53055: <http://trac.webkit.org/changeset/53055>
Comment 8 WebKit Commit Bot 2010-01-10 16:38:30 PST
All reviewed patches have been landed.  Closing bug.
Comment 9 Eric Seidel (no email) 2010-01-10 21:27:01 PST
Looks like this did not fix the problem:http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53062%20(8359)/results.html
Comment 10 Adam Barth 2010-01-10 21:58:33 PST
Strange.  Maybe the load event isn't firing somehow? If the load event fires, I don't see how it could possibly time out.
Comment 11 Daniel Bates 2010-01-11 00:35:06 PST
Created attachment 46263 [details]
Patch

Here is my attempt.

We can remove the use of layoutTestController.waitUntilDone() and instead test whether the parent of the newly opened window is equal to the current window. If so, then the test passed.

Notice, since this is a JavaScript URL, the parent of the newly opened window will be about:blank, if successful. And about:blank is different from the current window. Hence, we say the test fails when the parent of the newly opened window is not equal to the current window.
Comment 12 Adam Barth 2010-01-11 00:42:02 PST
Comment on attachment 46263 [details]
Patch

Thats an interesting test, but not what the test is supposed to be testing.  We're trying to see if the JavaScript runs at all.  The problem is the JavaScript runs asynchronously.  It's hard to tell whether the JavaScript isn't going to run or just plain hasn't run yet.
Comment 13 Eric Seidel (no email) 2010-01-11 13:57:29 PST
Another failure:
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53095%20(8391)/results.html
Comment 14 Adam Barth 2010-01-11 16:49:15 PST
This is failing often enough that we can try reducing the test case.  Maybe remove the window.open call and see what happens?
Comment 15 Brian Weinstein 2010-01-11 16:50:59 PST
(In reply to comment #14)
> This is failing often enough that we can try reducing the test case.  Maybe
> remove the window.open call and see what happens?

I would test it, but I have been unable to reproduce this on my machine. Does it need to be run with all of run-webkit-tests, or has anyone been able to reproduce this on their own machine?
Comment 16 Eric Seidel (no email) 2010-01-11 17:34:24 PST
This test just doesn't like us.  Failed again:
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53111%20(8401)/results.html
Comment 17 Eric Seidel (no email) 2010-01-13 23:50:45 PST
Not that you really need my reminder, but for book-keeping.  Still a common failure:
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53240%20(8501)/results.html

bug 32528 looks like a duplicate, or at least related.
Comment 18 Eric Seidel (no email) 2010-01-15 14:22:11 PST
Still our most common windows debug failure:
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53343%20(8577)/results.html

Dan/Adam: Should we just skip this, or do we have any clue why this is failing?
Comment 19 Adam Barth 2010-01-15 23:31:00 PST
Instead of skipping the test, we should investigate why it fails.  For example, you could try a patch that removes code from the test until it passes consistently.
Comment 21 Adam Barth 2010-02-03 00:00:35 PST
Please skip this test.  Assign the bug to me.  I won't forget it.  <-- famous last words.
Comment 22 Csaba Osztrogon√°c 2010-02-03 00:12:31 PST
(In reply to comment #21)
> Please skip this test.  Assign the bug to me.  I won't forget it.  <-- famous
> last words.

Done by http://trac.webkit.org/changeset/54275
Comment 23 Adam Barth 2010-03-10 18:38:35 PST
Committed r55826: <http://trac.webkit.org/changeset/55826>
Comment 24 Adam Barth 2010-03-10 18:39:15 PST
We have another test that has this same problem.  I've removed the test, but we should bring it back once we figure out how to test this case!
Comment 25 Adam Barth 2011-10-13 15:37:27 PDT
This doesn't appear to have been a problem recently.