Bug 17167 - Failures in fast/dom/Node/initial-values.html
Summary: Failures in fast/dom/Node/initial-values.html
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Eric Seidel (no email)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-03 15:54 PST by Eric Seidel (no email)
Modified: 2019-02-06 09:04 PST (History)
5 users (show)

See Also:


Attachments
Fix behaviour of nodeName for prefixed QualifiedName (3.35 KB, patch)
2009-02-13 04:45 PST, Julien Chaffraix
no flags Details | Formatted Diff | Diff
Updated version with better comments and more tests (7.53 KB, patch)
2009-02-18 17:04 PST, Julien Chaffraix
eric: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2008-02-03 15:54:56 PST
Failures in fast/dom/Node/initial-values.html

As previously mentioned in bug 17060, this test case tests for the exact behavior as spec'd
in DOM Level 3.  There are a few failures remaining for WebKit.

Failures unique to WebKit:
FAIL element.namespaceURI should be null (of type object). Was
http://www.w3.org/1999/xhtml (of type string).
FAIL element.nodeName should be html:pre. Was PRE.
FAIL element.namespaceURI should be null (of type object). Was
http://www.w3.org/1999/xhtml (of type string)

Failures shared by FF3b2:
FAIL attr.localName should be null (of type object). Was foo (of type string).
FAIL attr.localName should be null (of type object). Was foo (of type string).
FAIL doc.namespaceURI should be http://www.w3.org/1999/xhtml (of type string).
Was null (of type object).
FAIL element.localName should be null (of type object). Was pre (of type
string).
(FF3b2 fails with "PRE" instead of "pre")
FAIL element.localName should be null (of type object). Was pre (of type
string).
(FF3b2 fails with "pre" instead of "PRE" however.)
Comment 1 David Kilzer (:ddkilzer) 2008-02-23 13:30:17 PST
See also Bug 17048.

Comment 2 Julien Chaffraix 2009-02-13 04:45:17 PST
Created attachment 27655 [details]
Fix behaviour of nodeName for prefixed QualifiedName

This fixes "FAIL element.nodeName should be html:pre. Was PRE."
Comment 3 Eric Seidel (no email) 2009-02-13 09:29:53 PST
Comment on attachment 27655 [details]
Fix behaviour of nodeName for prefixed QualifiedName

Seems fine to me.
Comment 4 Alexey Proskuryakov 2009-02-14 02:47:21 PST
HTML5 section about APIs in HTML documents does not have a special case for elements with prefixes - should it?

The patch looks right to me, as well.
Comment 5 Ian 'Hixie' Hickson 2009-02-14 12:46:11 PST
I don't understand the question.
Comment 6 Alexey Proskuryakov 2009-02-14 13:07:18 PST
> I don't understand the question.

From HTML5:
----------
For HTML documents, and for HTML elements in HTML documents, certain APIs defined in DOM3 Core become case-insensitive or case-changing, as sometimes defined in DOM3 Core, and as summarized or required below. [DOM3CORE].

This does not apply to XML documents or to elements that are not in the HTML namespace despite being in HTML documents.

Element.tagName and Node.nodeName
These attributes must return element names converted to uppercase, regardless of the case with which they were created.
----------

In this bug, we discuss a case where nodeName doesn't convert the result to uppercase, even though the element is an HTML element in an HTML document.
Comment 7 Ian 'Hixie' Hickson 2009-02-14 13:35:26 PST
Why should it not become uppercase?
Comment 8 Alexey Proskuryakov 2009-02-14 13:59:55 PST
As far as I'm concerned, the main reason is that this is what Firefox and Opera do. Also, returning "HTML:PRE" instead of "html:pre" seems to serve no purpose at all - it would create an inconsistency for no practical compatibility reason, as clients that are only aware of HTML semantics would look for "PRE", not "HTML:PRE".

I'm deferring to Eric to explain why this is also what DOM 3 Core requires - I couldn't find anything in the spec that directly supported this claim.
Comment 9 Eric Seidel (no email) 2009-02-14 16:54:08 PST
Comment on attachment 27655 [details]
Fix behaviour of nodeName for prefixed QualifiedName

Removing the review flag so this doesn't get landed before we resolve this discussion.
Comment 10 Eric Seidel (no email) 2009-02-14 17:20:59 PST
(In reply to comment #8)
> I'm deferring to Eric to explain why this is also what DOM 3 Core requires - I
> couldn't find anything in the spec that directly supported this claim.

I wrote this test *forever* ago (assuming it was even me)... But I find this in the spec:

tagName has the value "elementExample". Note that this is case-preserving in XML, as are all of the operations of the DOM. The HTML DOM returns the tagName of an HTML element in the canonical uppercase form, regardless of the case in the source HTML document.

That's the discussion of tagName, but it suggests that for xhtml (which is what's under discussion), that case is preserved for all attributes, including prefix, since it's XML.
Comment 11 Alexey Proskuryakov 2009-02-15 01:29:41 PST
Actually, the case that is fixed here is in "Element creation using createElementNS on an HTML doc" section of the test, see <http://trac.webkit.org/export/41017/trunk/LayoutTests/fast/dom/Node/initial-values.html>.

But I think that compatibility and consistency are sufficient reasons for us to change the behavior.
Comment 12 Eric Seidel (no email) 2009-02-15 02:29:19 PST
Comment on attachment 27655 [details]
Fix behaviour of nodeName for prefixed QualifiedName

Marking r+ again.  At least ap and I agree. :)
Comment 13 Julien Chaffraix 2009-02-18 04:19:30 PST
Comment on attachment 27655 [details]
Fix behaviour of nodeName for prefixed QualifiedName

Sorry to reply to the discussion this late.

I had the same thoughts as Eric about the specification. Document.createElementNS will create an XHTML element per DOM spec (as it splits the localName to fill the prefix which is not done in HTML). To be consistent with the DOM then we also need to have Element.nodeName match the XHTML behaviour. This is also what the other browser are doing.

As we do not have a way to know whether an HTMLElement represents internally an XHTML element, the prefix check will correct at least part of the issue (non-prefixed element will continue to fail).
Clearing the review flag as I would like to update the test and the code to account for this.
Comment 14 Julien Chaffraix 2009-02-18 17:04:10 PST
Created attachment 27769 [details]
Updated version with better comments and more tests
Comment 15 Alexey Proskuryakov 2009-02-19 01:24:44 PST
Comment on attachment 27769 [details]
Updated version with better comments and more tests

+As we cannot test if an HTMLElement is an XHTML
+element, our fix is to check whether it has a prefix and then default
+to XML behaviour for nodeName.

I don't understand this comment (or a FIXME in HTMLElement.cpp) Where is "XHTML element" defined?

In Firefox, HTML elements created by parsing HTML documents (or via createElement) have a null namespace, which is not the case in WebKit and in HTML5. See also <http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsGenericHTMLElement.cpp#327>.

Changing the behavior for names with prefixes seemed logical and safe, but saying that XHTML elements should be different from HTML elements is an entirely different thing.
Comment 16 Julien Chaffraix 2009-02-19 14:51:57 PST
(In reply to comment #15)
> (From update of attachment 27769 [details] [review])
> +As we cannot test if an HTMLElement is an XHTML
> +element, our fix is to check whether it has a prefix and then default
> +to XML behaviour for nodeName.
> 
> I don't understand this comment (or a FIXME in HTMLElement.cpp) Where is "XHTML
> element" defined?

Maybe it is my interpretation of the DOM & HTML5 specification but an HTMLElement in WebKit can behave in 2 ways as stated in HTML5 and the DOM spec: it either uses the HTML-specific behaviour or the other one (nodeName is an exemple but other methods have the same dual behaviour). As a result, it defines 2 different elements (HTML and XHTML elements).
Other browsers can discriminate on the namespace to choose which algorithm to use (as you are pointing out). We cannot because all HTMLElement are in the same namespace.
 
> Changing the behavior for names with prefixes seemed logical and safe, but
> saying that XHTML elements should be different from HTML elements is an
> entirely different thing.

I am not saying that they should be different (internally we would use the same representation). However I am saying that they have a different behaviour with regard to the DOM and it is what is important here. One of the added tests shows that we are choosing the wrong nodeName algorithm for a non-prefixed element created by createElementNS in an HTML document.
Comment 17 Ian 'Hixie' Hickson 2009-02-19 15:02:31 PST
In HTML5, it's the document that has the HTML vs XML flag and an element acts as per its document's flag. It isn't done on a per-element basis.
Comment 18 Eric Seidel (no email) 2009-02-19 15:05:45 PST
(In reply to comment #17)
> In HTML5, it's the document that has the HTML vs XML flag and an element acts
> as per its document's flag. It isn't done on a per-element basis.

WebKit has an equivalent distinction.  document->isHTMLDocument() will tell you if your Document* is really an HTMLDocument* and thus you should be in "html" mode not XHTML mode.
Comment 19 Julien Chaffraix 2009-02-20 01:15:11 PST
(In reply to comment #18)
> (In reply to comment #17)
> > In HTML5, it's the document that has the HTML vs XML flag and an element acts
> > as per its document's flag. It isn't done on a per-element basis.
> 
> WebKit has an equivalent distinction.  document->isHTMLDocument() will tell you
> if your Document* is really an HTMLDocument* and thus you should be in "html"
> mode not XHTML mode.
> 

Exactly. This is the core of my comments: other browsers do such a distinction on an element level (using the namespace).
HTML5 removes the namespace distinction as HTML and XHTML elements uses the same namespace and places the distinction at the document level. However the second change will lead to compatibility bugs (this bug is an example).
I am just stating that my change only solves part of our current compatibility issue and that we may prefer to solve it entirely, which means a per-element policy that goes against HTML5. We may also decide that this is just a corner case and just side with HTML5.
Comment 20 Alexey Proskuryakov 2009-02-20 05:09:13 PST
FWIW, it seems that Mozilla didn't have a bug about fixing Gecko to use XHTML namespace for HTML elements. I've filed <https://bugzilla.mozilla.org/show_bug.cgi?id=479417>.
Comment 21 Eric Seidel (no email) 2009-05-11 05:42:27 PDT
It seems that this change still agrees with Opera and Mozilla, but disagrees with HTML5.  It's unclear as to if it agrees or disagrees with DOM Core 3.

In either case, it's a corner case.

I assume this does not break the document.createElement("foo:bar") case?  since the real web does that. :)  I'm sure we have test cases to cover that though.
Comment 22 Eric Seidel (no email) 2009-05-21 19:07:04 PDT
Comment on attachment 27769 [details]
Updated version with better comments and more tests

I'm OK with this.  The test should say:
+Element creation using createElementNS on an HTML doc:

Non-Prefixed Element creation, or HTML Element creation (whichever is more correct).
Comment 23 Alexey Proskuryakov 2009-05-21 20:47:57 PDT
I'm not sure if we should do this, now that Mozilla actively is being actively updated to match HTML5.
Comment 24 Eric Seidel (no email) 2009-05-21 20:54:24 PDT
Please cite the mozilla bug numbers, emails, or whatever information you have. :)  And feel free to r- the patch.  I'm leaving this r+ with intent to have Julien land it until someone else takes decisive action.
Comment 25 Alexey Proskuryakov 2009-05-21 21:00:37 PDT
See comment 20, <https://bugzilla.mozilla.org/show_bug.cgi?id=479417>.
Comment 26 Adam Barth 2009-06-02 00:57:57 PDT
Assigning to Eric for resolution.
Comment 27 Eric Seidel (no email) 2009-06-02 13:52:30 PDT
(In reply to comment #25)
> See comment 20, <https://bugzilla.mozilla.org/show_bug.cgi?id=479417>.

This patch does not change the namespaceURI behavior.  IT only changes the nodeName behavior.

Going to land this and close the bug (even though there are still other "failures" in this test).
Comment 28 Eric Seidel (no email) 2009-06-02 14:33:54 PDT
Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	LayoutTests/ChangeLog
	M	LayoutTests/fast/dom/Node/initial-values-expected.txt
	M	LayoutTests/fast/dom/Node/resources/initial-values.js
	M	WebCore/ChangeLog
	M	WebCore/html/HTMLElement.cpp
Committed r44369
Comment 29 Lucas Forschler 2019-02-06 09:04:00 PST
Mass moving XML DOM bugs to the "DOM" Component.