[Webkit-unassigned] [Bug 199610] New: script elements created by the transformToFragment method of XSLTProcessor are not executed on insertion into DOM tree

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=199610

            Bug ID: 199610
           Summary: script elements created by the transformToFragment
                    method of XSLTProcessor are not executed on insertion
                    into DOM tree
           Product: WebKit
           Version: Safari Technology Preview
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: XML
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: martin.honnen at gmx.de

This bug report is about the failure of WebKit to ensure that "script" elements generated by the "transformToFragment" method of the "XSLTProcessor" object are executed on insertion into the DOM tree.

There is no W3C or WhatWG specification of the XSLTProcessor object and its API methods like transformToFragment but as Mozilla introduced that API and other browsers like WebKit or Chrome decided to offer the same API the Mozilla implementation's behaviour can be regarded as a reference; furthermore, for the "transformToFragment" method both the W3C HTML5 spec (https://www.w3.org/TR/html50/scripting-1.html#scriptTagXSLT) as well as the WhatWG HTML spec (https://html.spec.whatwg.org/multipage/scripting.html#scriptTagXSLT) do include some notes on the exact behaviour of this method and generated script elements:

The XSLTProcessor.transformToFragment() method needs to create a fragment that is equivalent to one built manually by creating the elements using document.createElementNS(). For instance, it needs to create script elements that aren't "parser-inserted" and that don't have their "already started" flag set, so that they will execute when the fragment is inserted into a document.

Mozilla browsers implement this but neither WebKit/Safari nor Chromium/Chrome implement it; Chrome has an open bug https://bugs.chromium.org/p/chromium/issues/detail?id=266305 on this.

My own test cases are at https://martin-honnen.github.io/xslt/2019/transformToFragment-Test3.html (XSLTProcessor.transformToFragment creating an HTML fragment with an HTML "script" element with inline code) and https://martin-honnen.github.io/xslt/2019/transformToFragment-Test5.html (XSLTProcessor.transformToFragment creating an HTML fragment with an HTML "script" element referencing an internal script document).

These work in Mozilla, meaning the XSLT generated "script" elements are executed on insertion into the DOM tree, but fail in WebKit (and Chrome) where the scripts are not executed on insertion into the DOM tree.

There is also some ongoing work to integrate two test cases into the wpt test suite, the current pull requests result on Safari can be seen at https://staging.wpt.fyi/results/xslt/transformToFragment.window.html?diff&filter=ADC&run_id=212960008&run_id=248040010.

Looking at the implementation of "transformToFragment" in both Chromium and WebKit it seems the infrastructure to allow that generated "script" elements can be executed on insertion into the DOM tree already exists as the Range method "createContextualFragment" has the same demand and both Chromium and WebKit implement this with a particular ParserContentPolicy and the behaviour of createContextualFragment is compatible with Mozilla.

So the only thing missing in the WebKit source code seems to use the ParserContentPolicy AllowScriptingContentAndDoNotMarkAlreadyStarted explicitly in the method "createFragmentForTransformToFragment" where the "parseHTML" and "parseXML" methods of a fragment are called; so basically the fix would be to change the call

    fragment->parseHTML(sourceString, fakeBody.ptr());
to
    fragment->parseHTML(sourceString, fakeBody.ptr(), AllowScriptingContentAndDoNotMarkAlreadyStarted);

and the call 

    fragment->parseXML(sourceString, 0);
to
   fragment->parseXML(sourceString, 0, AllowScriptingContentAndDoNotMarkAlreadyStarted);

in that method https://github.com/WebKit/webkit/blob/master/Source/WebCore/editing/markup.cpp#L1217.

I am not set up to build Safari but in Chromium, as outlined in the relevant https://bugs.chromium.org/p/chromium/issues/detail?id=266305, I have tried the appropriate fix and then the test cases do work.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190709/0e1b19bd/attachment-0001.html>