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.
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.
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. :)
*** Bug 14944 has been marked as a duplicate of this bug. ***
(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.
Looks like http://trac.webkit.org/changeset/36652 fixed this.