15220 2007-09-14 17:03:49 -0700 Tests expect window.name to be reset between page loads 2010-08-09 16:23:21 -0700 1 1 1 Unclassified WebKit Tools / Tests 523.x (Safari 3) Mac OS X 10.4 RESOLVED FIXED HasReduction, LayoutTestFailure P2 Normal --- 1 mpComplete webkit-unassigned ddkilzer mihaip sam oldest_to_newest 460 0 mpComplete 2007-09-14 17:03:49 -0700 Run this command (all one line): run-webkit-tests fast/dom/Window/get-set-properties.html fast/loader/plain-text-document.html The second test will fail because the frame name is carried over from the first test. Some test that is normally run in between must reset the frame name, or else the DRT is restarted sometime between the two tests. I think a simple call to mainFrame->tree()->setName("") before each test is run should fix this. 403 1 ggaren 2007-09-17 12:06:07 -0700 That would fix the problem, but I think a better fix would be to change the test. Maintaining the frame's name between page loads is correct behavior. We don't want our tests to rely on assumptions of incorrect behavior. 374 2 ddkilzer 2007-09-18 08:45:17 -0700 Confirmed with a local debug build of WebKit r25545 with Safari 3 Public Beta v. 3.0.3 (522.12.1) on Mac OS X 10.4.10 (8R218). I've seen this failure before, but I don't recall whether any bugs were filed for it. The new-DRT-is-started-every-1000 tests would magically "fix" this in cases where tests that changed window.name were in different DRT runs. Has anyone tried "run-webkit-tests --nthly=10000" (to use a single instance of DRT) to see what kinds of failures one gets? (Assuming there are less than 10000 tests still. :) 369 3 ddkilzer 2007-09-18 08:49:22 -0700 *** Bug 14944 has been marked as a duplicate of this bug. *** 370 4 ddkilzer 2007-09-18 08:51:37 -0700 (In reply to comment #3) > *** Bug 14944 has been marked as a duplicate of this bug. *** Similar failures result here (single command line): $ run-webkit-tests fast/dom/Window http/tests/security These would probably all fail if "run-webkit-tests --nthly=10000" were tried as well. 262389 5 mihaip 2010-08-09 16:23:21 -0700 Looks like http://trac.webkit.org/changeset/36652 fixed this.