The XMLSerializer serializeToString method does not include namespaces on bare nodes. as a workaround, it is possible to wrap the node in a document, and then serialize the document instead, but this behavior does not match the behavior of Firefox 2.0 or 3.0, nor Opera.
The issue here is that the node in question belongs to an HTML document, so we serialize it accordingly.
Firefox and Opera use XML serialization for XMLSerializer, and HTML one for innerHTML. WebKit uses the same code for both, but checks document type.
Created attachment 136045[details]
Archive of layout-test-results from ec2-cr-linux-03
The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-03 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Created attachment 136220[details]
Archive of layout-test-results from ec2-cr-linux-01
The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment on attachment 136169[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=136169&action=review> Source/WebCore/editing/markup.cpp:762
> +String createMarkup(const Node* node, EChildrenOnly childrenOnly, Vector<Node*>* nodes, EAbsoluteURLs shouldResolveURLs, bool xmlFragmentSerialization)
Please use enum instead of bool. r- because of this.
> Source/WebCore/xml/XMLSerializer.cpp:44
> + return createMarkup(node, IncludeNode, 0, DoNotResolveURLs, true);
With enum, the semantics of this code will be much clearer.
Created attachment 137078[details]
Archive of layout-test-results from ec2-cr-linux-04
The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-04 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
(In reply to comment #11)
> (From update of attachment 136169[details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=136169&action=review
>
> > Source/WebCore/editing/markup.cpp:762
> > +String createMarkup(const Node* node, EChildrenOnly childrenOnly, Vector<Node*>* nodes, EAbsoluteURLs shouldResolveURLs, bool xmlFragmentSerialization)
>
> Please use enum instead of bool. r- because of this.
>
> > Source/WebCore/xml/XMLSerializer.cpp:44
> > + return createMarkup(node, IncludeNode, 0, DoNotResolveURLs, true);
>
> With enum, the semantics of this code will be much clearer.
Again a good suggestion with the enum, I tried to implement this in my latest patch.
About the failing testcase, I know the <br /> part is an improvement. We serialize now in xml mode so we end up with <br /> to feed to xslt, same as in FF. The ns addition on <head> is something which I am not sure libxslt or my patch is doing, will check later.
Cheers,
Rob.
Hi Ryosuke,
(In reply to comment #18)
> (From update of attachment 138579[details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=138579&action=review
>
> > LayoutTests/fast/dom/dom-serialize-namespace.html:1
> > +<html>
>
> You might want DOCTYPE here.
Thanks! However, should I rebaseline fast/xsl/xslt-processor.html? I am not sure how the end result should look, also in FF and Opera the test does not seem to work so I can't compare. Should I look into the test result differences more or do you know how it should look?
Cheers,
Rob.
Created attachment 138718[details]
Archive of layout-test-results from ec2-cr-linux-03
The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-03 Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'> Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
(In reply to comment #23)
> I do not believe this was ever landed.
Sorry guys, I can't remember exactly what happened but maybe there were still DRT tests failing with the final patch. I can have another look this weekend.
Created attachment 205267[details]
Archive of layout-test-results from webkit-ews-07 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-07 Port: mac-mountainlion Platform: Mac OS X 10.8.3
Created attachment 205308[details]
Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-11 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.3
Created attachment 205311[details]
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-05 Port: mac-mountainlion Platform: Mac OS X 10.8.3
Created attachment 205361[details]
Archive of layout-test-results from webkit-ews-10 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-10 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.3
Created attachment 205362[details]
Archive of layout-test-results from webkit-ews-08 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-08 Port: mac-mountainlion Platform: Mac OS X 10.8.3
Comment on attachment 205402[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=205402&action=review> Source/WebCore/editing/MarkupAccumulator.cpp:107
> + , m_fragmentSerialization(fragmentSerialization)
This implicit conversion to bool is bogus.
> Source/WebCore/editing/MarkupAccumulator.cpp:436
> + if (element->namespaceURI() == XMLNames::xmlNamespaceURI)
> + prefix = xmlAtom;
> + if (!prefix.isEmpty()) {
> + result.append(prefix);
> + result.append(':');
> + }
prefix is always empty unless we execute the assignment above: prefix = xmlAtom.
> Source/WebCore/editing/MarkupAccumulator.cpp:551
> - if (node->document()->isHTMLDocument())
> + if (m_fragmentSerialization != XMLFragmentSerialization && node->document()->isHTMLDocument())
It seems like we want to extract this condition as a helper function.
In fact, we might even want to add a boolean indicating this as a member variable to speed things up.
> Source/WebCore/editing/MarkupAccumulator.h:117
> + bool m_fragmentSerialization;
Why is this a boolean?
(In reply to comment #40)
> (From update of attachment 205402[details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=205402&action=review
>
> > Source/WebCore/editing/MarkupAccumulator.cpp:107
> > + , m_fragmentSerialization(fragmentSerialization)
>
> This implicit conversion to bool is bogus.
Right, see below.
> > Source/WebCore/editing/MarkupAccumulator.cpp:436
> > + if (element->namespaceURI() == XMLNames::xmlNamespaceURI)
> > + prefix = xmlAtom;
> > + if (!prefix.isEmpty()) {
> > + result.append(prefix);
> > + result.append(':');
> > + }
>
> prefix is always empty unless we execute the assignment above: prefix = xmlAtom.
Right, I was thinking of adding more cases where we assign prefix for certain namespaces like we do for attributes. To fix this bug this seems to be actually the only one I need. I guess I'll eliminate prefix temp var for now.
> > Source/WebCore/editing/MarkupAccumulator.cpp:551
> > - if (node->document()->isHTMLDocument())
> > + if (m_fragmentSerialization != XMLFragmentSerialization && node->document()->isHTMLDocument())
>
> It seems like we want to extract this condition as a helper function.
> In fact, we might even want to add a boolean indicating this as a member variable to speed things up.
A helper is a good idea, will do that.
> > Source/WebCore/editing/MarkupAccumulator.h:117
> > + bool m_fragmentSerialization;
>
> Why is this a boolean?
Seems like a mistake on my behalf, fixing.
Will have a new patch up soon.
Comment on attachment 205487[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=205487&action=review> Source/WebCore/ChangeLog:9
> + http://html5.org/specs/dom-parsing.html#xmlserializer. In this mode
Could you refer to a specific revision of http://domparsing.spec.whatwg.org instead?
Since it's a live standard, the content at the given URL is going to change, and
I'd like to be able to identify which version of the specification is implemented in this patch in the future.
> Source/WebCore/editing/MarkupAccumulator.cpp:276
> - if (attribute.name() == XMLNSNames::xmlnsAttr) {
> + if (attribute.name() == XMLNSNames::xmlnsAttr || (inXMLFragmentSerialization() && attribute.localName() == XMLNSNames::xmlnsAttr.localName() && attribute.namespaceURI().isEmpty())) {
It seems like this is part of the DOM4 spec here:
http://dom.spec.whatwg.org/#locate-a-namespace
instead of it being specified in the serialization spec.
If that were the case, then we should probably add a new member function to Attribute that implements this locate-a-namespace algorithm.
> Source/WebCore/editing/MarkupAccumulator.cpp:304
> + // Suppress xmlns: for xml namespace, it is implied
> + if (inXMLFragmentSerialization() && namespaceURI == XMLNames::xmlNamespaceURI)
> + return;
Where is this specified? The current specification is extremely vague about this.
> Source/WebCore/editing/MarkupAccumulator.cpp:434
> + if (inXMLFragmentSerialization() && element->prefix().isEmpty()) {
> + if (element->namespaceURI() == XMLNames::xmlNamespaceURI) {
> + result.append(xmlAtom);
> + result.append(':');
> + }
> + }
Ditto.
> Source/WebCore/editing/MarkupAccumulator.cpp:436
> + if ((inXMLFragmentSerialization() || !element->document()->isHTMLDocument()) && namespaces && shouldAddNamespaceElement(element))
Ditto.
> Source/WebCore/editing/MarkupAccumulator.cpp:491
> + if ((inXMLFragmentSerialization() || !documentIsHTML) && namespaces && shouldAddNamespaceAttribute(attribute, *namespaces))
> + appendNamespace(result, prefixedName.prefix(), prefixedName.namespaceURI(), *namespaces);
Ditto.
Created attachment 205645[details]
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-06 Port: mac-mountainlion Platform: Mac OS X 10.8.3
Created attachment 205673[details]
Archive of layout-test-results from webkit-ews-11 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-11 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.3
Created attachment 205742[details]
Archive of layout-test-results from webkit-ews-15 for mac-mountainlion-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-15 Port: mac-mountainlion-wk2 Platform: Mac OS X 10.8.3
Created attachment 205743[details]
Archive of layout-test-results from webkit-ews-06 for mac-mountainlion
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-06 Port: mac-mountainlion Platform: Mac OS X 10.8.3
Hi Ryosuke,
(In reply to comment #45)
> (From update of attachment 205487[details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=205487&action=review
>
> > Source/WebCore/ChangeLog:9
> > + http://html5.org/specs/dom-parsing.html#xmlserializer. In this mode
>
> Could you refer to a specific revision of http://domparsing.spec.whatwg.org instead?
> Since it's a live standard, the content at the given URL is going to change, and
> I'd like to be able to identify which version of the specification is implemented in this patch in the future.
I tried to do that in my latest patch.
> > Source/WebCore/editing/MarkupAccumulator.cpp:276
> > - if (attribute.name() == XMLNSNames::xmlnsAttr) {
> > + if (attribute.name() == XMLNSNames::xmlnsAttr || (inXMLFragmentSerialization() && attribute.localName() == XMLNSNames::xmlnsAttr.localName() && attribute.namespaceURI().isEmpty())) {
>
> It seems like this is part of the DOM4 spec here:
> http://dom.spec.whatwg.org/#locate-a-namespace
> instead of it being specified in the serialization spec.
It is a bit different, this one does not look at ancestors. I changed this code a bit in my latest patch.
> If that were the case, then we should probably add a new member function to Attribute that implements this locate-a-namespace algorithm.
>
> > Source/WebCore/editing/MarkupAccumulator.cpp:304
> > + // Suppress xmlns: for xml namespace, it is implied
> > + if (inXMLFragmentSerialization() && namespaceURI == XMLNames::xmlNamespaceURI)
> > + return;
>
> Where is this specified? The current specification is extremely vague about this.
I removed this in my latest patch, but it is covered under Namespace constraint: Reserved Prefixes and Namespace Names in http://www.w3.org/TR/REC-xml-names/.
> > Source/WebCore/editing/MarkupAccumulator.cpp:434
> > + if (inXMLFragmentSerialization() && element->prefix().isEmpty()) {
> > + if (element->namespaceURI() == XMLNames::xmlNamespaceURI) {
> > + result.append(xmlAtom);
> > + result.append(':');
> > + }
> > + }
>
> Ditto.
This is done in order not to loose the namespace associated with the element, I put a comment for that in my latest patch.
> > Source/WebCore/editing/MarkupAccumulator.cpp:436
> > + if ((inXMLFragmentSerialization() || !element->document()->isHTMLDocument()) && namespaces && shouldAddNamespaceElement(element))
>
> Ditto.
I think this actually needs no explanation, for xml serializing we simply may want to add a namespace depending on the element.
> > Source/WebCore/editing/MarkupAccumulator.cpp:491
> > + if ((inXMLFragmentSerialization() || !documentIsHTML) && namespaces && shouldAddNamespaceAttribute(attribute, *namespaces))
> > + appendNamespace(result, prefixedName.prefix(), prefixedName.namespaceURI(), *namespaces);
>
> Ditto.
For xml serializing we simply may want to add a namespace depending on the attribute.
Note that the latest patch finally shows up all green!
Comment on attachment 206684[details]
Patch
View in context: https://bugs.webkit.org/attachment.cgi?id=206684&action=review> Source/WebCore/ChangeLog:9
> + http://html5.org/specs/dom-parsing.html#xmlserializer (23 May 2013). In this mode
Could you refer to a specific hash instead?
> Source/WebCore/ChangeLog:27
> + (WebCore::MarkupAccumulator::serializeNodesWithNamespaces): makes sure xml namespace/prefix is known so it is never used in namespace declarations.
> + (WebCore::MarkupAccumulator::appendNamespace): Avoid adding namespace declarations that do not differ from current default namespace.
> + (WebCore::MarkupAccumulator::appendOpenTag): Print xml prefix if the element's namespace is XML to avoid conflicts.
> + (WebCore::MarkupAccumulator::appendAttribute): Force any calculated prefix/namespace pair into the generated namespace.
> + (WebCore::MarkupAccumulator::shouldAddNamespaceAttribute): Also take into account xmlns attributes with no namespace.
> + (WebCore::MarkupAccumulator::shouldSelfClose): Force self-closing to create well-formed XML elements.
> + * editing/MarkupAccumulator.h: Use EFragmentSerialization.
It's still unclear to me which parts are referring to the spec mentioned about
and which parts are matching Firefox/IE. It's helpful have that information in the change log, not in the code.
> Source/WebCore/editing/MarkupAccumulator.cpp:144
> + // Make sure xml prefix and namespace are always known to ensure these Namespace constraints:
> + // The prefix xml MUST NOT be declared as the default namespace.
> + // The prefix xml MAY, but need not, be declared (XMLNames specification, Namespace constraint: Reserved Prefixes and Namespace Names)
Instead of copying & pasting the spec. text, can we refer to a specific section from which this text is copied?
> Source/WebCore/editing/MarkupAccumulator.cpp:436
> + // According to DOM3 appendix B Namespace Normalization we now should create a default namespace declaration to make this namespace well-formed.
> + // However, XMLNames specification, Namespace constraint: Reserved Prefixes and Namespace Names says:
> + // "The prefix xml MUST NOT be declared as the default namespace.", so use the xml prefix explicitly.
Ditto about referring to sections of the specifications.
Thanks for the review!
(In reply to comment #59)
> (From update of attachment 206684[details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=206684&action=review
>
> > Source/WebCore/ChangeLog:9
> > + http://html5.org/specs/dom-parsing.html#xmlserializer (23 May 2013). In this mode
>
> Could you refer to a specific hash instead?
I added a commit hash before landing.
> > Source/WebCore/ChangeLog:27
> > + (WebCore::MarkupAccumulator::serializeNodesWithNamespaces): makes sure xml namespace/prefix is known so it is never used in namespace declarations.
> > + (WebCore::MarkupAccumulator::appendNamespace): Avoid adding namespace declarations that do not differ from current default namespace.
> > + (WebCore::MarkupAccumulator::appendOpenTag): Print xml prefix if the element's namespace is XML to avoid conflicts.
> > + (WebCore::MarkupAccumulator::appendAttribute): Force any calculated prefix/namespace pair into the generated namespace.
> > + (WebCore::MarkupAccumulator::shouldAddNamespaceAttribute): Also take into account xmlns attributes with no namespace.
> > + (WebCore::MarkupAccumulator::shouldSelfClose): Force self-closing to create well-formed XML elements.
> > + * editing/MarkupAccumulator.h: Use EFragmentSerialization.
>
> It's still unclear to me which parts are referring to the spec mentioned about
> and which parts are matching Firefox/IE. It's helpful have that information in the change log, not in the code.
I reworded the commit log, I still thing the per method explanations are useful as well.
> > Source/WebCore/editing/MarkupAccumulator.cpp:144
> > + // Make sure xml prefix and namespace are always known to ensure these Namespace constraints:
> > + // The prefix xml MUST NOT be declared as the default namespace.
> > + // The prefix xml MAY, but need not, be declared (XMLNames specification, Namespace constraint: Reserved Prefixes and Namespace Names)
>
> Instead of copying & pasting the spec. text, can we refer to a specific section from which this text is copied?
Done.
> > Source/WebCore/editing/MarkupAccumulator.cpp:436
> > + // According to DOM3 appendix B Namespace Normalization we now should create a default namespace declaration to make this namespace well-formed.
> > + // However, XMLNames specification, Namespace constraint: Reserved Prefixes and Namespace Names says:
> > + // "The prefix xml MUST NOT be declared as the default namespace.", so use the xml prefix explicitly.
>
> Ditto about referring to sections of the specifications.
Done.
I discovered before landing that one change in appendAttribute is not needed to fix this bug, I left it out for now but think I'll include it in a patch for bug 22958.
2012-04-06 09:39 PDT, Rob Buis
2012-04-06 11:36 PDT, WebKit Review Bot
2012-04-08 18:49 PDT, Rob Buis
2012-04-09 07:27 PDT, WebKit Review Bot
2012-04-13 05:38 PDT, Rob Buis
2012-04-13 06:30 PDT, WebKit Review Bot
2012-04-24 09:34 PDT, Rob Buis
2012-04-24 19:07 PDT, WebKit Review Bot
2013-06-22 19:37 PDT, Rob Buis
2013-06-23 04:46 PDT, Build Bot
2013-06-23 08:04 PDT, Rob Buis
2013-06-24 09:21 PDT, Rob Buis
2013-06-24 10:45 PDT, Build Bot
2013-06-24 11:03 PDT, Build Bot
2013-06-24 19:14 PDT, Rob Buis
2013-06-24 21:01 PDT, Build Bot
2013-06-24 21:18 PDT, Build Bot
2013-06-25 07:16 PDT, Rob Buis
2013-06-25 14:16 PDT, Rob Buis
2013-06-26 07:06 PDT, Rob Buis
2013-06-27 15:23 PDT, Rob Buis
2013-06-27 16:27 PDT, Build Bot
2013-06-28 00:06 PDT, Build Bot
2013-06-28 12:21 PDT, Rob Buis
2013-06-28 14:05 PDT, Build Bot
2013-06-28 14:27 PDT, Build Bot
2013-06-28 14:36 PDT, Rob Buis
2013-07-15 14:08 PDT, Rob Buis