Bug 28744 – XSLTProcessor transformToFragment mistakenly treats source node as root one

• Component: XML
• Status: NEW

[Martin Honnen]

Created attachment 38618 [details]
HTML document with a JavaScript test case using XSLTProcessor transformToFragment

WebKit allows XSLT transformations to be run by Javascript code, exposing the same API that Mozilla introduced: https://developer.mozilla.org/index.php?title=en/The_XSLT%2F%2FJavaScript_Interface_in_Gecko/Interface_List
There is however a major incompatibility between WebKit and between Mozilla. The first argument to the transformToFragment method takes a DOM node and Mozilla (and Opera) then apply the XSLT transformation with that node as the initial context node while WebKit seems to always apply the XSLT transformation to the ownerDocument node of the DOM node passed to transformToFragment.
So with Mozilla the API can be used to apply an XSLT transformation to a certain DOM node (e.g. an element in a larger document) while WebKit always applies the transformation to the complete document.

That is an incompatibility. As the API was introduced by Mozilla and then adapted by WebKit I think WebKit should aim to behave like Mozilla.

The test case I am going to attach runs a simple XSLT transformation with transformToFragment. The stylesheet has two templates, one matching the document node (match="/") and a second matching a 'foo' element (match="foo"). Then transformToFragment is called with a 'foo' element node in a larger XML document being passed in as the first argument. Mozilla and Opera that way start the transformation by applying the match="foo" template while WebKit starts the transformation by applying the match="/" template leading to a transformation result that differs strongly between Mozilla and WebKit.

[Alexey Proskuryakov]

This is indeed a serious bug, but the mechanism is somewhat different than described above. The implementation of transformToFragment takes a subtree with a root at source node, and creates a new document from it. So, the "<xsl:template match="/">" rule matches "<foo>" node.

Like bug 14101, this will be quite difficult to fix, because our DOM tree cannot be directly processed by XSL, so we cannot just pass a node from DOM.

[Ahmad Saleem]

I am still able to reproduce this bug in Safari 15.6 on macOS 12.5 using attached test case and it shows "Test failed." and it is same with Chrome Canary 106. Only Firefox Nightly 105 shows "Test succeeded.". Thanks!

[Ahmad Saleem]

*** Chrome Canary 116 & Safari 16.5 / STP171 ***

<div xmlns="http://www.w3.org/1999/xhtml"><p>bar</p></div>


*** Firefox Nightly 115 ***

<p xmlns="http://www.w3.org/1999/xhtml">bar</p>