Bug 15220

Summary: Tests expect window.name to be reset between page loads
Product: WebKit Reporter: Matt Perry <mpComplete>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ddkilzer, mihaip, sam
Priority: P2 Keywords: HasReduction, LayoutTestFailure
Version: 523.x (Safari 3)   
Hardware: Mac   
OS: OS X 10.4   

Description Matt Perry 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.
Comment 1 Geoffrey Garen 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.
Comment 2 David Kilzer (:ddkilzer) 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. :)

Comment 3 David Kilzer (:ddkilzer) 2007-09-18 08:49:22 PDT
*** Bug 14944 has been marked as a duplicate of this bug. ***
Comment 4 David Kilzer (:ddkilzer) 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.

Comment 5 Mihai Parparita 2010-08-09 16:23:21 PDT
Looks like http://trac.webkit.org/changeset/36652 fixed this.