- From: Curt Arnold <carnold@houston.rr.com>
- Date: Fri, 22 Feb 2002 04:48:20 -0600
- To: <www-dom-ts@w3.org>
- Message-ID: <001801c1bb8e$73fcebf0$a800a8c0@CurtMicron>
The typical caution about trusting anything posted at 4 AM. I've just committed a new build.xml and DOMTestSuite.js. build.xml was changes to make the target directories for dom2-core-gen-jsunit and dom2-html-gen-jsunit consistent with the layout of the DOM L1. DOMTestSuite.js has a series of changes: The existing sniffing code had been alleged to misidentify Mozilla as IE, however no specifics were provided. I've encorporated the detection logic from http://www.mozilla.org/docs/web-developer/sniffer/browser_type.html which will hopefully eliminate the problem. The Mozilla implementations of isDOMExceptionCode were always returning true instead of returing (ex.code == code). This was an oversight, but should not change the Mozilla results. The Adobe SVG implementation of isDOMExceptionCode still always returns true. However, there wasn't enough time to map the returned exception.number to DOMException.code's. (Always returning true from isDOMExceptionCode will cause tests that expect an exception to pass as long as some exception is raised.) If svg_alltests is run from Mozilla, the Mozilla SVG DOM implementation will be tested. Running this test on a Mozilla version without SVG will cause an very unpleasant number of browser windows to be opened. Running the test on a Mozilla with SVG will cause only 52 windows to be opened. Repeatedly running the DOM L1 Core tests on Mozilla would give slightly different failure counts (typically off by one) which does support the assertion that pressing enter in response to an "loading document" alert might cause an false failure. It seems impossible to determine if a document has been loaded before exiting the load method since any registered load event listener will never get called until the load() method is exited regardless of the number of times that alert() is called. Likewise, neither will the document.documentElement.tagName change. Perfectly resolving the problem would either require a test framework that supported asychronrous tests or a synchronous load method for Mozilla.
Received on Friday, 22 February 2002 05:48:26 UTC