mirror of
https://github.com/odoo/owl.git
synced 2025-10-06 19:59:41 +07:00
Samuel Degueldre
b25e988628
Firefox will not serialize the xmlns attributes of node inside XMLDocuments, see https://bugzilla.mozilla.org/show_bug.cgi?id=175946 it will only output an xmlns attribute if the node being serialized has a non-null namespaceURI. When compiling templates, we currently use a special attribute, "block-ns" to keep track of the namespace, but we do not make use of the namespace to create the elements that will be serialized to the compiled block string. This causes a difference in behaviour between Chrome and Firefox: since we end up with an Element with two attributes: the block-ns attribute and the xmlns attribute. Chrome will serialize both, but Firefox will only serialize the block-ns because the Element does not have a namespaceURI. To fix this issue, we get rid of the block-ns magic attribute completely, and use xmlns instead. We also use the namespace when creating intermediate elements that will be used to create the serialized block string: the namespace is only used to create the elements but *not* set as an attribute, as this would cause chrome to serialize it twice, causing a duplicate attribute error when parsing it further down the line. When creating the template element for the block at runtime, the xmlns attribute is used both as the namespace with which to create the element, and set as an attribute, this doesn't cause issues when serializing later because the namespaceURI is never serialized as an attribute when serializing an HTML document[1], so we avoid the double-serialization in Chrome, and when doing HTML serialization, Firefox will correctly serialize the attribute. It's desirable that the xmlns is set as an attribute to allow users to use owl to render SVG, and then use the HTML serialization of it as a SVG even outside the context of an HTML document (eg to generate an SVG file or an SVG data URL). [1]: https://w3c.github.io/DOM-Parsing/#xml-serialization