We ignore the supplied sourcenode and use its owning document instead. Both for the main processing, and for processing global variables. Patch comming up
Comment on attachment 110269 [details] [diff] [review] patch to fix please ignore the changes to the output-handler. They are not part of this bug. Forgot to save before attaching
Would you mind saying a little bit more precisely what's wrong? Which entry points and whatnot. And I'd prefer a patch with just the stuff in it that belongs here.
Created attachment 110359 [details] [diff] [review] patch to fix The problem exists with all entrypoints in module. The problem is that instead of processing using the supplied sourcenode, we get it's ownerdocument and run the transformation using that. We also process top-level variables using this document-node. To fix this I had to let the ProcessorState keep an mSourceNode instead of an mSourceDocument.
Hmm, actually, how does this fit with section 5.1 of the XSLT spec? You claim the "root node" is the node that we get supplied? http://www.w3.org/TR/xslt#section-Processing-Model
yeah, I think we should support starting the transformation at any node. We will always start the processing using the document-node (or root-node) when transforming using a processing-instruction.
Created attachment 112459 [details] [diff] [review] sync to tip
Comment on attachment 112459 [details] [diff] [review] sync to tip this is different enough that i think i need a new sr..
Comment on attachment 112459 [details] [diff] [review] sync to tip here you go, firstname.lastname@example.org
Comment on attachment 112459 [details] [diff] [review] sync to tip due to simplicity of the patch it is very lowrisk. It will also only affect pages using XSLT.
Comment on attachment 112459 [details] [diff] [review] sync to tip a=asa (on behalf of drivers) for checkin to 1.3beta.
checked in. Thanks for reviews