- Go to the above URL.
- Type http://home.houston.rr.com/curta/japanese.xml in the test suite input
The browser hangs.
The tests specified in the japanese.xml files should run and the page should get
updated dynamically with the test results.
More comments from Curt Arnold (firstname.lastname@example.org) who patched NIST's test
harness to try to get it to work in Mozilla:
Here are the problems that I needed to work around:
1. mozconf.xml (a XHTML variant of template.xml) did not display correctly
when the extension was .xml, but did when it was .html. Radio button labels
did not appear and centering or borders of tables were different.
2. Mozilla would not display an .XHTML file that only specified a public
identifier in its doctype.
to be done with IE and InterDev. Not being able (or at least not knowing
4. Switching to HTML caused the processing instructions to disappear from
IE5's DOM meaning that I had to find a substitute for the template markers
(I used <div title="?target data"> in its place, but that it probably why
the IE5 version runs the tests but doesn't display the tables)
5. Asynchronous parsing required some massive reorganization of the code and
caused the IE5 variant to crash to large test suites (could run japanese.xml
but crashed on xmltest.xml). If synch parsing is added, then mozconf.js (a
variant of harness.js) should be rederived from harness.js and the current
My though would be just to add a optional boolean to the load method:
One implementation detail could be the load event handling. If it is
difficult to fire the "load" and related events with synch parsing, I'd just
say synch parsing fires no events.
I've put copies of ie5conf.html, ie5conf.js, mozconf.html, mozconf.xml (to
show rendering issues) and mozconf.js to http://home.houston.rr.com/curta/
In its current state, it should go in the CVS somewhere (/xml/mozilla?) with
disclaimers that it is an early work in progress.
You can run it from the site, type
http://home.houston.rr.com/curta/japanese.xml in the test suite field and
press run. It should display a few diagnostic messages and then return a
version. Attempting to run the suite from Mozilla causes a lock up, but
before any XML specific code is encountered.
Even if it is abandoned due to better scripts from the Netscape team, it
does show problems that people would have bring significant XML code to the
Marking qawanted and helpwanted.
QA work needed: test and file new bugs for the mozilla related problems
mentioned in Curt's email
Development work needed: Fix this bug so that we can get the NIST test suite to
work in Mozilla.
A big thank you to Curt for attempting this port to Mozilla!
I want to talk to Eric Krock before making a decision on whether this is a beta
3 candidate. Removing the nsbeta3- marker from the status whiteboard.
Question: Is using the XMLExtras facilities for parsing and synchronous loading
an acceptable solution to some of the problems seen?
Marking nsbeta3- (ekrock + nisheeth).
Created attachment 15903 [details]
stdlog from MacsBug, busted out of apparent loop
A quick review of mozconf.js shows that in line 140, inside of the test for a
PI, there is the following code:
140: child = xmlcode.nextChild;
xmlcode should be xmlnode (defined in line 139) and nextChild should be
nextSibling. This results in child being undefined resulting an infinite loop
since the test at line 121 tests child against null. I haven't looked at the
logic to see if it is correct though.
I did a quick hack on Brownell's original IE5 test suite using synchronous
XMLHttpRequest calls for both IE and Mozilla. It isn't complete yet since I
have yet to remove all of his IE dependent node navigation but I have learned a
1. IE's XMLHttpRequest object does not expand Entities so the OASIS
xmlconf.xml file can not be used, although you can iterate through the
individual xml test files. There may be some complications due to the need
to consolidate the test results but I don't think it is insurmountable.
I don't think the xmlextra version of XMLHttpRequest expands entities
either although I may be wrong about that.
Is there a programmatic way of expanding the entities defined in
2. There is no way in either XMLHttpRequest object to specify validating vs.
non-validating as far as I can tell. You can specify validating on the IE
XML parser, but the xmlextras parser only handles strings... so that is out
3. It would really be nice if xmlextras XMLParser supported loading
synchronously from files *and* allowed validation to be specified.
Even the emptyDocument.load method would be cool *if* it supported
synchronous calls and specification of validating or non-validating parses.
As it stands, it appears that a cross-browser (Mozilla/IE5.5) non-validating
XML parser test can be completed using synchronous XMLHttpRequest objects.
The URL is no longer valid. I changed it to the official NIST DOM test suite page.
The page does not cause a hang, but I do not see any tests to run either. It
seems NIST is also working on making the tests run in Mozilla. I have sent an
email asking if I could help them.
There seems to be a hacked version of the NIST DOM test suite at SourceForge
that should work in MSXML3, Adobe's SVG viewer and Xerces-COM. It still does not
work in Mozilla :/
NIST is working on making their test suites work with Mozilla. DOM test suite
should take maybe 3 more weeks, after which they might request our help in test
harness or some such.
Unless there are some code level changes required to make the tests work after
they are done, I don't think I am the correct owner for this bug.
Assigning to Prashant, QA for XML DOM. The test suite is big, so if they request
help it would be in our interests to get it working. This suite would also help
in shaking out the bugs introduced with the landing of the DOM conversion jst
and jband are working on. ETA sometime during 0.9.1.
any update on the test suite or bug fixing that might be needed
to run the tests? I'm going to unset the target milestone until
we here more. lets reset as soon as we learn the tests are available.
I've been working with the NIST/W3C DOM Test Suite effort and have finally
gotten the suite to run with Mozilla 0.9.3. See
This is really good news!
Johnny, could you look at the testcases that crash (3) or cause other problems?
Anyone else, now that there are tests that run, wanna jump in to help make them
better (there are some kludgles needed for Mozilla)?
I downloaded the NIST DOM Suite and I will hopfully be able to debug the three
tests that hang/crash mozilla (they still do). Most of the tests we fail come
from the following problems:
1) General suckiness of attribute node support
2) document.createEntityReference isn't implemented
3) document.doctype is null for XML documents with no doctype (but isn't that
correct per DOM1 Core spec? The test suite seems to think it's wrong)
4) Lack of entity nodes support
I'll look into the problems more deeply another day.
Could we get a status update on this, has this been done already?
This is part of the W3C DOM TS now afaik. It now uses jsUnit. There has been
work to upgrade jsUnit to be cross browser and to modify the DOM TS to be more
cross browser as well.
See recent posts to http://lists.w3.org/Archives/Public/www-dom-ts/ for an update.
I've been running the DOM TS for a while now.