[Webkit-unassigned] [Bug 55357] XSLT extension functions

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Mar 2 09:11:24 PST 2011


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





--- Comment #3 from Martin Blom <martin at blom.org>  2011-03-02 09:11:24 PST ---
(In reply to comment #2)
> Does this also work in Firefox? It's not obvious why this functionality is a good addition to WebKit.

Being able to extend XSLT with custom functions is very useful. Think of all the good things that has come from the EXSLT project, for instance.

> Running arbitrary JavaScript during transformations sounds like it could trigger lots of subtle bugs, including security ones.

Calling JavaScript from the XSLT processor can only be initialized by a call to XSLTProcessor.tranformToDocument()/transformToFragment() so the only thing that we are aware of is when the callback initializes another transformation.

We have a proposed solution for this in bug 41348: Remove global variables from XSLTProcessorLibxslt.cpp

> > This is why we no longer serialize the DOM to text and feed it into the other DOM's parser, but
> instead traverse the tree and manually build the other DOM.
> 
> This is an independent change that should be done in a separate patch. It could enable fixing issues like bug 14101, possibly at the cost of some formal spec compliance.

The DOM construction thing does not really help with the bug you refer to, since the libxslt API does not provide a way to specify anything else than strings or XPath expressions for parameters.

It might be possible, however, use a similar approach that we used in the patch to register a special "parameter lookup" XPath function that converts the WebKit XPath::Value into something libxslt likes (see extFunction() and xpathResult() in the patch)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list