Just tested mozilla with W3C DOM Level 1 Conformance Test Suit. Got 25 failures and 63 errors. I hope this bug can be useful as "top bug" for all related bugs so people would be able to track "depandancy tree" for "DOM level 1"-dependant events. The nice goal would be to have both these numbers 0. (For IE6 they are 18 and 10). Please be compliant...

With Win98SE, 2002011203, I get 58 errors, 19 failures, out of 290 tests. Confirming. DOM people: given that all I can really do is run tests & log bugs, how can I best help here?

For this bug, someone needs to sort out the errors, identify the existing bugs in Bugzilla that correspond to them and file new bugs if there are none, and attach these bugs as dependencies of this one.

For now a clear description of how to run said tests would be most helpful (the site has next to no info, the zip archive has no documentation included). If someone can put the tests up somewhere web-accessible that would be great....

Boris, eh ? Try reading index.htm :)

A few notes for reference purposes: - The precise number of failures/errors seems to vary from run to run, which seems worrying (e.g. I just got 85 total on my first run, 89 on my second) Further investigation seems to show there are some complications when running the "alltests" file: I suspect some of the hairier errors are disrupting the tests that immediately follow them. - at least a few of these problems are multiple occurrences of the same bug, which may, in turn, be masking other problems. I helped choess do a bit of bug hunting last night and we found the following existing bugs: attrdefaultvalue attrnotspecifiedvalue (these both appear to be failing due to bug 93614) attrsetvaluenomodificationallowederrEE (appears to be related to bug 56758) attrspecifiedvalueremove (appears to be bug 93614 again) characterdataindexsizeerrdeletedatacountnegative characterdataindexsizeerrreplacedatacountnegative characterdataindexsizeerrsubstringcountnegative (these three are bug 16610) I'll try to dig for more of these when I get a chance...

next instalment: we also fail cdatasectiongetdata cdatasectionnormalize both with a "xxxx has no properties" bug 49442 _may_ be relevant, but this seems to be more directly caused by bug 125110

Sigh... bug 125110 is very, very much an evangelism bug. see comments therein.

this bug can be used as a "top bug"/"meta bug"/"tracking bug", but the issue/issues discussed in bug 125110 needs to be resolved.

changing priority to P3

I wrote (comment 5 above): > The precise number of failures/errors seems to vary from run to run, which > seems worrying (e.g. I just got 85 total on my first run, 89 on my second) I'm no expert, but it sounds like the problems discussed in bug 125110 could cause this? OK, the problems described in bug 125110 notwithstanding, I'm gonna keep plugging away and try to track down as many of these as I can. Some of them may well be real bugs. So, next instalment: characterdataappenddatanomodificationallowederrEE.html and characterdatadeletedatanomodificationallowederrEE.html both seem to be hitting bug 56758 too. characterdatainsertdatanomodificationallowederrEE.html seems to be hitting bug 9850

Just FYI: For mozilla 0.9.9, built from SRPM on RH Linux, it is 58 errors and 19 failures. 5 errors and 6 failures were fixed since 0.9.8. With this pace, we'll have 0:0 after another 12 releases:)

> For mozilla 0.9.9 [...] it is 58 errors and 19 failures. 5 errors and > 6 failures were fixed since 0.9.8. Some of the problems mentioned in bug 125110 mean that the results obtained are not necessarily 100% reproducable. For a start, the number of errors/failures can depend upon how quickly you dismiss the alert dialogs. Those issues are now under discussion with the W3C, and hopefully there will be a revised Test Suite release at some point.

For online, unofficial, demonstration versions of the DOM Core 1, DOM HTML 1, DOM Core 2 and DOM HTML 2 tests see http://bclary.com/dom-ts/

Mass-reassigning bugs to dom_bugs@netscape.com

See also http://www.w3.org/Bugs/Public/buglist.cgi?product=DOM+TS&component=DOM+Level+1&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&order=Bug+Number.

sayrer, how are we doing on this bug now? You've checked in mochikit tests for DOM Core 1...

(In reply to comment #16) > sayrer, how are we doing on this bug now? You've checked in mochikit tests for > DOM Core 1... we fail a ton of DTD-related tests (see the summary of the test run). DTD stuff isn't high priority.

1) Depends on Bug 42976? 2) It's not better to transform this bug to a meta bug? This is the list of dom1 bugs: http://tinyurl.com/3z5gyh/ 3) I run the test with a blank profile of Fx trunk. I've got 15 errors and 15 failures. This is the log: http://pazziaumana.netsons.org/dom1-err-fx3.html do you need a more detailed log? 4) Those tests are really updated and reliable? I can't run Java test on my pc, and the JS test can't be run with Safari 3.1.1, that seems to me odd.

Furthermore I tested it on Fx2 and the 4th error doesn't happen. A regression? 4. http://www.w3.org/2004/04/ecmascript/level1/core/hc_documentgetdoctype.html:hc_documentgetdoctype failed "nodeName" Expected html (string) but was HTML (string) Stack trace follows: > JsUnitException > _assert > assertEquals > hc_documentgetdoctype

Was there a discussion on this somewhere? It seems like deciding that DOM test suite compliance is a WONTFIX is a significant policy decision.

This is DOM1, which has since been superceded by DOM2, DOM3, and the DOM Core specification currently in development. And in particular, the tests we still fail in the DOM1 test suite require behavior that contradicts the behavior required by those later specifications.