Last Comment Bug 51247 - Test harness for NIST DOM test suite does not work in Mozilla
: Test harness for NIST DOM test suite does not work in Mozilla
Status: RESOLVED FIXED
: helpwanted
Product: Core
Classification: Components
Component: XML (show other bugs)
: Trunk
: x86 Windows NT
: -- normal (vote)
: ---
Assigned To: Prashant Desale
: Ashish Bhatt
Mentors:
http://xw2k.sdct.itl.nist.gov/dom/ind...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-09-03 19:22 PDT by Nisheeth Ranjan
Modified: 2003-11-02 10:46 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
stdlog from MacsBug, busted out of apparent loop (30.35 KB, text/plain)
2000-09-29 20:21 PDT, Kurt Weinschenker
no flags Details

Description Nisheeth Ranjan 2000-09-03 19:22:35 PDT
- 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 2000-09-03 19:32:34 PDT
More comments from Curt Arnold (carnold@houston.rr.com) 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 2000-09-03 20:01:21 PDT
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) 2000-09-05 11:09:27 PDT
Question: Is using the XMLExtras facilities for parsing and synchronous loading 
an acceptable solution to some of the problems seen?
Comment 4 Nisheeth Ranjan 2000-09-11 16:43:51 PDT
Marking nsbeta3- (ekrock + nisheeth). 
Comment 5 Kurt Weinschenker 2000-09-29 20:21:28 PDT
Created attachment 15903 [details]
stdlog from MacsBug, busted out of apparent loop
Comment 6 Bob Clary [:bc:] 2000-10-18 17:36:12 PDT
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:] 2000-10-20 04:57:01 PDT
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) 2001-01-29 14:53:26 PST
Taking.
Comment 9 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-03-12 17:23:48 PST
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) 2001-03-12 17:44:13 PST
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) 2001-04-13 11:08:47 PDT
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 2001-05-08 21:04:06 PDT
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 2001-09-05 20:01:45 PDT
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) 2001-09-06 08:59:30 PDT
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 2001-10-27 15:05:21 PDT
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) 2002-05-29 14:49:09 PDT
Could we get a status update on this, has this been done already? 
Comment 17 Bob Clary [:bc:] 2002-05-29 15:11:50 PDT
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] - away till Aug 1st 2003-11-02 10:46:34 PST
I've been running the DOM TS for a while now.

Note You need to log in before you can comment on or make changes to this bug.