| 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 / Tests | Assignee: | 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
Eric Seidel (no email)
2010-01-07 15:29:21 PST
Hit this again just now: http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53039%20(8329)/results.html 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. 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. 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? Created attachment 46229 [details]
Patch
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 on attachment 46229 [details] Patch Clearing flags on attachment: 46229 Committed r53055: <http://trac.webkit.org/changeset/53055> All reviewed patches have been landed. Closing bug. Looks like this did not fix the problem:http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53062%20(8359)/results.html Strange. Maybe the load event isn't firing somehow? If the load event fires, I don't see how it could possibly time out. 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 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.
Another failure: http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53095%20(8391)/results.html This is failing often enough that we can try reducing the test case. Maybe remove the window.open call and see what happens? (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? This test just doesn't like us. Failed again: http://build.webkit.org/results/Windows%20Debug%20(Tests)/r53111%20(8401)/results.html 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. 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? 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. 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 Please skip this test. Assign the bug to me. I won't forget it. <-- famous last words. (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 Committed r55826: <http://trac.webkit.org/changeset/55826> 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! This doesn't appear to have been a problem recently. |