[webkit-dev] DOM L1 Core tests analysis

[Maciej Stachowiak]

On Jun 22, 2005, at 12:29 PM, Curt Arnold wrote:

> I was able to drop the self-hosted HTML tests for DOM Level 1 Core  
> into the WebCore/layout-tests directory.  The first
> run created the "-expected.txt" files and on a second run all the  
> tests "succeeded" (in the sense that the response had
> not changed from the first run).  Doing a grep on the expected  
> files for "failure" and "error" identified the following tests  
> which I have added a brief analysis of the cause of the failure.

Hi Curt,

I much-belatedly tried dropping in the Level 1 Core tests (at least  
the HTML version) and they seem to do pretty well as layout tests. I  
get 193 success, 45 failure. One thing that concerns me, though, is  
that some of the tests that Safari fails appear to be failed by all  
browsers that I could get my hands on. For example, Mac IE, Firefox  
and Opera all fail this test:

html/level1/core/hc_attrappendchild1.html

Every browser I tried failed at least a couple dozen of the tests,  
though not all failed the exact same set.


> Safari seems to have serious issues with the self-hosted XHTML  
> tests which appears to be due to a failure to pick up the entity  
> declarations in the document type declaration, however I haven't  
> tried to track those down.  I don't know whether I should expect  
> WebKit to have any support for XHTML.

It does have support, but we don't really do entities.

> I will later see what happens when the L2 Core and L2 HTML self- 
> hosted tests are dropped in.
>
> Manipulation of attributes and attribute child nodes appears to be  
> the most significant problem area, however these are problem areas  
> for many implementations.  The apparent lack of an implementation  
> for Document.cloneNode causes all of the multi-document tests the  
> self-tests implementation depends on that method to create the  
> second document.

That sounds like a serious problem - is there any way to change the  
tests to get a second document in a more portable way? Perhaps they  
could use a frame to hold a second document. The spec says that  
behavior of cloneNode() on a Document is implementation-dependent,  
and no browser supports it, so it seems like a bad idea to rely on it.

Regards,
Maciej