362347 - transformToStream() method for nsIXSLTProcessor

Status: RESOLVED WONTFIX

(Core :: XSLT, enhancement)

Description

[Matthew Gertner]

We are very interested in using Transformiix in our extension. The one clear issue that I see is the lack of a method in nsIXSLTProcessor for writing the transformation to a stream rather than creating a DOM. I've studied the implementation and it looks like this would be straightforward to implement. Please let me know what your view is on this and whether you would like me to submit a patch. This is highly general functionality that I should think would be useful to other parties as well.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

transformToStream should be easy except that we need to guarentee that the recipient of the stream does not modify the DOM of the stylesheet or the source document midway the transformation.

transformToString might be easier and safer to do.

The only issue is that we'd probably want to reuse the XML serializer since the functionality is practically the same.

Comment 2

[Axel Hecht]

Jonas, are you worried about "run-to-completion" in that case? Yeah, that's tricky. The question would be, should we have transformToStream on an internal interface then?

Regarding the xmlserializer, that should pull the content, whereas we would push the content in XSLT, right? So some stuff could surely be factored, but I wouldn't want to create a dom and serialize. 

I'd hope this method would be good enough to evaluate serialize-and-parse for d-o-i, too, which even more calls for stream and not complete string, at least at some level of API. At the very least, transformToStream should have d-o-i supported, IMHO.

This has to be my first XSLT bug comment of the year, I almost made it :-(.

Comment 3

[Peter Van der Beken [:peterv]]

Yeah, the serializers would be of no use, but the standalone output handlers might be.

Comment 4

[Matthew Gertner]

transformToStream() would be much more efficient for larger output volumes than transformToString(). Is the issue with the stream consumer modifying the input DOM or stylesheet simply that this would cause unexpected behavior/crash, or is there a security risk? I'm not sure I understand the practical implications of this since my assumption was that this interface can only be used by extensions anyway, and they are trusted (so can't we just trust them to "do the right thing"?).

Also, how would use of an internal interface help? Do you mean an interface that is not available to extensions? In this case, this wouldn't help us since we are an extension.

Comment 5

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

The issue is that if the stream consumer modifies the input/stylesheet DOM there can easily be crashes that are security risks (many crashes are).

By internal we mean not exposed to web pages, so extensions could still use it.

I guess I might be fine with exposing transformToStream to extensions, but i'm a bit nervous that they accidentally allow page script to execute mid transform.


Hmm.. I wonder if we could simply attach an nsIMutationObserver to the source document and somehow abort the transformation if any mutation is done. Ooh, or maybe even use nsMutationGuard. The latter may be better since it's hard to attach nsIMutationObservers to all involved documents given things like exslt:node-set and other extension functions.

Using nsMutationGuard the output handler could return a failure code if any mutations has happened during the call to the stream consumer. This means that we'll abort on mutations to unrelated documents too, but I think that may be the only way to do it.

Comment 6

[Axel Hecht]

I guess that'd fail if we ever use transformToStream for generating documents with d-o-i.

Given that we compile stylesheets, those should be safe, I guess. nodeset() should create new nodes that are only rooted in the processor, right? Leaves only the source documents, which are not that hard to track, IMHO.

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

do you mean d-o-e? I don't see why that is affected by nsMutationGuard.

Yeah, the stylesheet document is probably fine to change. exslt:node-set() and soon exslt:match() creates nodes that are owned by the source document but orphaned. So we have to attach an observer to each subtree returned by the function. We'd have to do that no matter which document owned these subtrees.

Then there is the general extension functions mechanism that we have no control over whatsoever.

Comment 8

[Matthew Gertner]

I'm not sure about the mutation guard. The thing is, what we want to do is implement nsIDOM... interfaces on top of our own document representation, then use the engine to pump the transformed documents into a stream. So we will have to deal with the mutability issues ourselves, and I wouldn't want the transformation to fail if some webpage changes or whatever.

How about making the mutation detection optional? Something like:

void transformToStream(in nsIDOMDocument aDoc, in nsIOutputStream aStream, in PRBool failOnMutation);

At least this makes it easy for extension authors to do the right thing.

Comment 9

[Peter Van der Beken [:peterv]]

(In reply to comment #7)
> exslt:node-set() and
> soon exslt:match() creates nodes that are owned by the source document but
> orphaned. So we have to attach an observer to each subtree returned by the
> function. We'd have to do that no matter which document owned these subtrees.

How would anyone get at these nodes though, since they're orphaned trees?

(In reply to comment #8)
> The thing is, what we want to do is
> implement nsIDOM... interfaces on top of our own document representation

Are you saying you want to transform a document that is not build out of Gecko dom nodes?

Comment 10

[Axel Hecht]

(In reply to comment #9)
> How would anyone get at these nodes though, since they're orphaned trees?

I was wondering myself, and I guess that getElementById might work. Though my jsshell html-based testing doesn't return orphaned divs on 2.0. Which may be a bug, the spec doesn't say that it shouldn't. getElementsByTagName does mention the Document tree, through.

Comment 11

[Matthew Gertner]

(In reply to comment #9)
> Are you saying you want to transform a document that is not build out of Gecko
> dom nodes?

Yes, I've been assuming that as long as we implement the appropriate nsIDOM... interfaces, the transformation engine will be able to process our documents. Is that incorrect?

Comment 12

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

You need to implement a whole lot more than the nsIDOM* interfaces. At the very least you'll have to implement nsINode/nsIContent/nsIDocument as well. Basically it's not something that I would recommend, but it's never been tried before so it might work.

Wrt exslt:node-set nodes. Yeah, might be impossible to reach them right now, though an extension funktion might change that