Bug 33349 - http/tests/security/xss-DENIED-window-open-javascript-url.html timed out on Windows Debug Bot
Summary: http/tests/security/xss-DENIED-window-open-javascript-url.html timed out on W...
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Adam Barth
Depends on:
Blocks: 32528
  Show dependency treegraph
Reported: 2010-01-07 15:29 PST by Eric Seidel (no email)
Modified: 2011-10-13 15:37 PDT (History)
7 users (show)

See Also:

Patch (1.69 KB, patch)
2010-01-09 23:38 PST, Adam Barth
no flags Details | Formatted Diff | Diff
Patch (3.52 KB, patch)
2010-01-11 00:35 PST, Daniel Bates
abarth: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
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


Added by abarth 3 weeks ago:
Comment 1 Eric Seidel (no email) 2010-01-09 15:25:29 PST
Hit this again just now:
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:

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]
Comment 6 Nikolas Zimmermann 2010-01-10 16:18:07 PST
Comment on attachment 46229 [details]

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]

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]

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]

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

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:

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.