[webkit-dev] DOM L1 Core tests analysis

[Curt Arnold]

On Jul 25, 2005, at 11:00 PM, Maciej Stachowiak wrote:

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

I haven't seen a browser that has implemented the child nodes of an  
attribute node, however it is in the spec and passed by most if not  
all XML parsers.  The only implementation that I know that passes all  
the L1 Core tests is Xerces-J.

I remember working on an update of the results matrix (side-by-side  
results from 7-8 Java implementations + IE, Mozilla and Opera), not  
sure if I ever finished or posted it.  I'll see if I can find what I  
did with that since it is helpful to identify what tests are commonly  
failed by browsers.

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

Would you care to point me to the XHTML parsing code?


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


The "abstract" test (that is the XML document that defines the test)  
does not specify how the two documents are to be obtained.  The  
transformation of the abstract test for JSUnit-hosted framework use  
two IFRAME elements to provide the two documents and would not  
attempt to use cloneNode to obtain the second document.  The self- 
hosted production are more constrained since they attempt to modify  
the test document so it also contains the test script and the test  
framework with the minimal disturbance to the test document.  The  
cloneNode was an expedient way to get the self-hosted tests running  
on SVG (where cloneNode is generally supported).

It may be possible to modify the self-hosted framework to do a brute- 
force copy.  I think that would be easier than trying to insert an  
additional IFRAME into the test document without messing things up.   
I'll investigate and see if I can't come up with something.