RESOLVED FIXED 15220
Tests expect window.name to be reset between page loads 
https://bugs.webkit.org/show_bug.cgi?id=15220
Summary Tests expect window.name to be reset between page loads
Matt Perry
Reported 2007-09-14 17:03:49 PDT
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.
Attachments
Add attachment proposed patch, testcase, etc.
Geoffrey Garen
Comment 1 2007-09-17 12:06:07 PDT
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.
David Kilzer (:ddkilzer)
Comment 2 2007-09-18 08:45:17 PDT
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. :)
David Kilzer (:ddkilzer)
Comment 3 2007-09-18 08:49:22 PDT
*** Bug 14944 has been marked as a duplicate of this bug. ***
David Kilzer (:ddkilzer)
Comment 4 2007-09-18 08:51:37 PDT
(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.
Mihai Parparita
Comment 5 2010-08-09 16:23:21 PDT
Looks like http://trac.webkit.org/changeset/36652 fixed this.
Note You need to log in before you can comment on or make changes to this bug.