I'm going to use this as a sort of "master bug" to track bugs covering all the W3C DOM tests we don't pass.
So far, I have made bugs block this that cover 34 tests we don't pass. There are 11 others: HTMLIsIndexElement01/2/3, HTMLTableElement39, and the 7 tests that are disabled.
OK, now the bugs that block this cover all 38 failing tests. The 7 disabled tests still don't have bugs (that I know of).
Last I tried, the disabled HTMLDocument tests all passed. I think this was due to a change in the tokenizer.
I've just done a diff between the DOM tests in the WebKit CVS HEAD and the corresponding tests generated from the W3C CVS. The following differences were noticed: selfhtml.js: The WebKit version has been modified to call window.layoutTestController.dumpAsTest() for level1/core, level2/core and level2/event and additionally calls layoutTestController.waitUntilDone and layoutTestController.notifyDone in level2/html. The changes would appear to have no effect when the tests are run outside of the automated tests and are adequately identified as local modifications. It would likely be good if these were consistent. level2/events/dispatchEvent12: Appears the patch for bug 4491 was incompletely applied and has been reported as bug 4570. Other level2/events tests differ from the W3C generated ones by whitespace only due to the original load of the Events tests was from a slightly out of date snapshot. level2/html/HTMLBaseElement01 and HTMLBaseElement02: Bug 4391 has not been applied, added to prerequisites list for this bug. level2/html/HTMLFormElement10.js: Has a call to layoutTestController.waitUntilDone(). Not marked as a WebKit modification. Possibly unnecessary in light of changes to selfhtml.js. In a perfect world, I think it would be better if you could push the dumpAsTest and other tweaks to dumpRenderTree's behavior into command line switches that the scripts would use for tests in the dom tree eliminating the need for WebKit mods to the tests.
I took care of the selfhtml.js issue by making all 4 of the copies identical. Maybe some day we can come up with a way to run the tests without modifying this file, but in the short term there's no urgency to this. I applied Curt's corrections for dispatchEvent12, HTMLBaseElement01, and HTMLBaseElement02 and marked the relevant bugs resolved. I removed the change in HTMLFormElement10.js. I re-enabled the HTMLDocument tests as suggested by Anders. There are 3 disabled tests, HTMLFormElement10, HTMLFrameElement09, and HTMLIFrameElement11, and there are still no bugs covering those. I believe we have bugs covering every other failure.
There are now four test failures that are not covered by a specific bug report: dom/html/level2/html/HTMLFormElement10.html dom/html/level2/html/HTMLIFrameElement11.html dom/html/level2/html/HTMLFrameElement09.html dom/html/level2/html/HTMLIsIndexElement02.html In addition, there are two failures covered by bug 4493: dom/html/level2/core/createDocument08.html dom/html/level2/core/createDocumentType04.html Two failures covered by bug 4566: dom/html/level1/core/hc_documentinvalidcharacterexceptioncreateelement.html dom/html/level1/core/hc_documentinvalidcharacterexceptioncreateelement1.html One failure covered by bug 4567: dom/html/level1/core/hc_elementremoveattribute.html Four failures covered by bug 4568: dom/html/level1/core/hc_attrappendchild2.html dom/html/level1/core/hc_nodeappendchildinvalidnodetype.html dom/html/level1/core/hc_nodeinsertbeforeinvalidnodetype.html dom/html/level1/core/hc_nodereplacechildinvalidnodetype.html Five failures covered by bug 4569: dom/html/level1/core/hc_attrappendchild5.html dom/html/level1/core/hc_attrinsertbefore6.html dom/html/level1/core/hc_nodeappendchildnewchilddiffdocument.html dom/html/level1/core/hc_nodeinsertbeforenewchilddiffdocument.html dom/html/level1/core/hc_nodereplacechildnewchilddiffdocument.html And three failures covered by bug 4571: dom/html/level2/html/HTMLCollection07.html dom/html/level2/html/HTMLCollection08.html dom/html/level2/html/HTMLTableElement39.html
Added bug 4828 to cover the failure in HTMLIsIndexElement02.html.
The HTMLFrameElement09 test was failing because the test didn't agree with the contents of the "frame.html" file. I fixed that in our copy.
This is now covered by bug 4847: dom/html/level2/html/HTMLFormElement10.html This was fixed by correcting mistakes in how the test directory is set up: dom/html/level2/html/HTMLFrameElement09.html This is now covered by bug 4828: dom/html/level2/html/HTMLIsIndexElement02.html And this is the single remaining failing test that needs its own bug report. The only reason I haven't written one yet is that I only know that the test is disabled, I don't know why or what's going wrong. dom/html/level2/html/HTMLIFrameElement11.html
I'm looking into why dom/html/level2/html/HTMLIFrameElement11.html is disabled. It currently reports a failure in both Safari and Firefox.
I see now. This is an error in the test, http://bugzilla.opendarwin.org/show_bug.cgi?id=4891. I've fixed our local version, and filed a bug with w3.org as recommended.
All dependent bugs has been closed but there were some tests mentioned in Comment 06, which were not dependent on any bug. I looked them in the test suite from following link: Link - https://www.w3.org/2004/04/ecmascript/level2/html/alltests.html ___ From below: In first test case, HTMLFormElement10 - all browsers (Safari 15.6, Chrome Canary 106 and Firefox Nightly 105) passed. Following two were not present on test-suite: dom/html/level2/html/HTMLIFrameElement11.html & dom/html/level2/html/HTMLFrameElement09.html While the last one "HTMLIsIndexElement02" failed in all browsers as mentioned for test 1. Since all browsers are in consensus and also all dependent bugs are fixed. I am going to mark this as "RESOLVED CONFIGURATION CHANGED". If I am wrong, please mark / tag this appropriately. Thanks!