Bug 15220
| Summary: | Tests expect window.name to be reset between page loads | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Matt Perry <mpComplete> |
| Component: | Tools / Tests | Assignee: | 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 | ||
Matt Perry
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
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)
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)
*** Bug 14944 has been marked as a duplicate of this bug. ***
David Kilzer (:ddkilzer)
(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
Looks like http://trac.webkit.org/changeset/36652 fixed this.