51247 - Test harness for NIST DOM test suite does not work in Mozilla

Status: RESOLVED FIXED

(Core :: XML, defect)

Description

[Nisheeth Ranjan]

- Go to the above URL.
- Type http://home.houston.rr.com/curta/japanese.xml in the test suite input 
field.

Actual Result:
The browser hangs.

Expected Result:
The tests specified in the japanese.xml files should run and the page should get 
updated dynamically with the test results.

Comment 1

[Nisheeth Ranjan]

More comments from Curt Arnold ([e-mail]) who patched NIST's test 
harness to try to get it to work in Mozilla:

<EMAIL>
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.

3. Lack of Javascript debugging capability meant that most development had
to be done with IE and InterDev.  Not being able (or at least not knowing
how) to parse an XML file from JavaScript in Netscape 4.x prevented using
its JavaScript debugger.

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
form abandoned.

My though would be just to add a optional boolean to the load method:

document.implementation.load(uri,"text/xml",true);

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
number to tests passed that is consistent with the console javascript
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
Mozilla platform.
</EMAIL>

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!

Comment 2

[Nisheeth Ranjan]

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.

Comment 3

[vidur (gone)]

Question: Is using the XMLExtras facilities for parsing and synchronous loading 
an acceptable solution to some of the problems seen?

Comment 4

[Nisheeth Ranjan]

Marking nsbeta3- (ekrock + nisheeth). 

Comment 5

[Kurt Weinschenker]

Attachment: stdlog from MacsBug, busted out of apparent loop

Comment 6

[Bob Clary [:bc] (inactive)]

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.

Comment 7

[Bob Clary [:bc] (inactive)]

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 
some things.

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
    xmlconf.xml?

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
    (for now).

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.

Comment 8

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Taking.

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 10

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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 :/

http://xmlconf.sourceforge.net/dom1/ecmascript/

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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.

Comment 12

[chris hofmann]

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.

Comment 13

[carnold]

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 
http://lists.w3.org/Archives/Public/www-dom-ts/2001Sep/0005.html

Comment 14

[Heikki Toivonen (remove -bugzilla when emailing directly)]

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)?

Comment 15

[Fabian Guisset]

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.

Comment 16

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Could we get a status update on this, has this been done already? 

Comment 17

[Bob Clary [:bc] (inactive)]

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.

Comment 18

[Peter Van der Beken [:peterv]]

I've been running the DOM TS for a while now.