NEW 5492
XSLTProcessor ignores namespaces
https://bugs.webkit.org/show_bug.cgi?id=5492
Summary XSLTProcessor ignores namespaces
Eric Seidel (no email)
Reported 2005-10-24 21:53:49 PDT
At least getParameter, setParameter and removeParameter ignore namespaces. There are currently test cases to show this. The reason why I left these failing as they are, is that I'm not sure libxml2 supports namespaces... infact, I'm not even sure what "namespace" support would mean for parameters. "prefix" suport makes some sense. But does that mean that we are expected to translate from namespace URIs to prefixes when used? It's not clear at all what mozilla does in this case, or what they indended when they wrote their documentation.
Attachments
Zip archive of 1 xsl and 1 xhtml test files (1.02 KB, application/octet-stream)
2006-08-17 12:23 PDT, Lamar Goddard
no flags
Another file showing the incorrect behavior of WebKit's setParameter method. (1.83 KB, text/html)
2010-04-12 08:21 PDT, Scott Trenda
no flags
Lamar Goddard
Comment 1 2006-08-17 12:23:06 PDT
Created attachment 10100 [details] Zip archive of 1 xsl and 1 xhtml test files It looks like it's not just the parameters that ignore namespaces. Elements don't have their namespace set properly for the transform. The attached identity_new_class.xsl file is the identity transform but it also adds a class to each node if a class isn't already present. If you load the attached xsltprocessor_namespace.xhtml file in WebKit it does the transform, but because the namespace isn't properly passed to the transform, the resulting nodes have no namespace and are treated like plain xml. Also because the parameters don't pass in their namespace, the xsl:param doesn't match and it gets set to the empty string. It behaves as expected when loading the xsltprocessor_namespace.xhtml file in FireFox showing an unordered list with two blue list items "Does" and "Work".
Scott Trenda
Comment 2 2010-04-12 08:21:09 PDT
Created attachment 53164 [details] Another file showing the incorrect behavior of WebKit's setParameter method. +1 for this, although it looks like no one's seen this bug in at least two years. It's appearing in Chrome as well. It looks like these lines in the source note this bug and are ultimately to blame: void XSLTProcessorImpl::setParameter(DOMStringImpl *namespaceURI, DOMStringImpl *localName, DOMStringImpl *value) { // FIXME: namespace support? m_parameters.replace(DOMString(localName).qstring(), new DOMString(value)); } SharedPtr<DOMStringImpl> XSLTProcessorImpl::getParameter(DOMStringImpl *namespaceURI, DOMStringImpl *localName) const { // FIXME: namespace support? if (DOMString *value = m_parameters.find(DOMString(localName).qstring())) return value->impl(); return 0; } void XSLTProcessorImpl::removeParameter(DOMStringImpl *namespaceURI, DOMStringImpl *localName) { // FIXME: namespace support? m_parameters.remove(DOMString(localName).qstring()); } Please get this taken care of with all appropriate speed. For the record, Firefox and Opera return the correct result from the transformation. These are the outputs from the most current versions of the following browsers as of 4/12/2010: Firefox/Opera: XSLTProcessor param namespace test $param = non-namespaced param $ns1:param = namespace-1 param $ns2:param = namespace-2 param XSLTProcessor param namespace test $param = non-namespaced param $ns1:param = not set $ns2:param = not set Chrome/Safari: XSLTProcessor param namespace test $param = namespace-2 param $ns1:param = not set $ns2:param = not set XSLTProcessor param namespace test $param = non-namespaced param $ns1:param = namespace-1 param $ns2:param = namespace-2 param
Scott Trenda
Comment 3 2010-04-12 08:25:15 PDT
Also worth noting that this happens on Chrome and Safari in Windows as well, not just OSX.
jared
Comment 4 2021-01-15 08:27:34 PST Comment hidden (spam)
Note You need to log in before you can comment on or make changes to this bug.