Bug 33349 – http/tests/security/xss-DENIED-window-open-javascript-url.html timed out on Windows Debug Bot

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Tools / Tests

[Eric Seidel (no email)]

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

[Eric Seidel (no email)]

Hit this again just now:
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53039%20(8329)/results.html

[Eric Seidel (no email)]

Strange that this has occurred in batches of twos today.  First:
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53034%20(8324)/
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53035%20(8325)/

Then:
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53039%20(8329)/
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53040%20(8330)/

I wonder if that's cooincidence or somehow related to how this fails.

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

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?

[Adam Barth]

Created attachment 46229 [details]
Patch

[Nikolas Zimmermann]

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.

[WebKit Commit Bot]

Comment on attachment 46229 [details]
Patch

Clearing flags on attachment: 46229

Committed r53055: <http://trac.webkit.org/changeset/53055>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Eric Seidel (no email)]

Looks like this did not fix the problem:http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53062%20(8359)/results.html

[Adam Barth]

Strange.  Maybe the load event isn't firing somehow? If the load event fires, I don't see how it could possibly time out.

[Daniel Bates]

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.

[Adam Barth]

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.

[Eric Seidel (no email)]

Another failure:
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53095%20(8391)/results.html

[Adam Barth]

This is failing often enough that we can try reducing the test case.  Maybe remove the window.open call and see what happens?

[Brian Weinstein]

(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?

[Eric Seidel (no email)]

This test just doesn't like us.  Failed again:
http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53111%20(8401)/results.html

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

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?

[Adam Barth]

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.

[Csaba Osztrogonác]

Unfortunately it timed out at all times. :( (r54260-r54271)

http://build.webkit.org/results/Windows%20Debug%20%28Tests%29/r54271%20%289357%29/results.html

http://build.webkit.org/results/Windows%20Debug%20%28Tests%29/r54270%20%289356%29/results.html

http://build.webkit.org/results/Windows%20Debug%20%28Tests%29/r54269%20%289355%29/results.html

[Adam Barth]

Please skip this test.  Assign the bug to me.  I won't forget it.  <-- famous last words.

[Csaba Osztrogonác]

(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

[Adam Barth]

Committed r55826: <http://trac.webkit.org/changeset/55826>

[Adam Barth]

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!

[Adam Barth]

This doesn't appear to have been a problem recently.