|
Description
Christopher Schmidt
2007-12-17 20:07:17 PST
Confirmed with a local debug build of WebKit r28774 with Safari 3.0.4 (523.12) on Mac OS X 10.4.11 (8S165). 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. This is a bug in markup.cpp. Created attachment 136035 [details]
Patch
Comment on attachment 136035 [details] Patch Attachment 136035 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12264985 New failing tests: fast/innerHTML/innerHTML-custom-tag.html editing/pasteboard/paste-noscript-svg.html 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 136169 [details]
Patch
Comment on attachment 136169 [details] Patch Attachment 136169 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12372189 New failing tests: fast/xsl/xslt-processor.html 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 137071 [details]
Patch
Comment on attachment 137071 [details] Patch Attachment 137071 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12392908 New failing tests: fast/xsl/xslt-processor.html 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. Comment on attachment 137071 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=137071&action=review > Source/WebCore/editing/MarkupAccumulator.cpp:491 > + if (!m_fragmentSerialization == XMLFragmentSerialization && node->document()->isHTMLDocument()) You mean m_fragmentSerialization != XMLFragmentSerialization? Created attachment 138579 [details]
Patch
Comment on attachment 138579 [details] Patch 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. 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. Comment on attachment 138579 [details] Patch Attachment 138579 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/12518413 New failing tests: fast/xsl/xslt-processor.html 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
Has this patch been landed? I do not believe this was ever landed. (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 205259 [details]
Patch
Comment on attachment 205259 [details] Patch Attachment 205259 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/971324 New failing tests: fast/xsl/xslt-processor.html svg/custom/xlink-prefix-in-attributes.html 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 205270 [details]
Patch
Created attachment 205301 [details]
Patch
Comment on attachment 205301 [details] Patch Attachment 205301 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/961768 New failing tests: fast/xsl/xslt-processor.html 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
Comment on attachment 205301 [details] Patch Attachment 205301 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/981235 New failing tests: fast/xsl/xslt-processor.html 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 205354 [details]
Patch
Comment on attachment 205354 [details] Patch Attachment 205354 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/977329 New failing tests: inspector/elements/set-outer-html-for-xhtml.xhtml 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
Comment on attachment 205354 [details] Patch Attachment 205354 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/926539 New failing tests: inspector/elements/set-outer-html-for-xhtml.xhtml 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
Created attachment 205402 [details]
Patch
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. Created attachment 205423 [details]
Patch
Created attachment 205487 [details]
Patch
Uploaded one more time to see if it goes green. 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 205641 [details]
Patch
Comment on attachment 205641 [details] Patch Attachment 205641 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/974242 New failing tests: fast/xsl/xslt-processor.html 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
Comment on attachment 205641 [details] Patch Attachment 205641 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/995333 New failing tests: fast/xsl/xslt-processor.html 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 205732 [details]
Patch
Comment on attachment 205732 [details] Patch Attachment 205732 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/981812 New failing tests: inspector/elements/set-outer-html-for-xhtml.xhtml 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
Comment on attachment 205732 [details] Patch Attachment 205732 [details] did not pass mac-ews (mac): Output: http://webkit-queues.appspot.com/results/866608 New failing tests: svg/batik/filters/feTile.svg inspector/elements/set-outer-html-for-xhtml.xhtml 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
Created attachment 205744 [details]
Patch
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! Created attachment 206684 [details]
Patch
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. Committed r152685: <http://trac.webkit.org/changeset/152685> Mass moving XML DOM bugs to the "DOM" Component. |