Re: XSLT processing model in Mozilla

Jonas Sicking wrote:
> John J. Barton wrote:
>> Jonas Sicking wrote:
>>> Since you're not providing a testcase, I'm left with guessing what's 
>>> going on.
>> There here:
>> http://fireclipse.svn.sourceforge.net/viewvc/*checkout*/fireclipse/trunk/FireclipseTests/WebContent/testXSLT.xml 
>>
>> http://fireclipse.svn.sourceforge.net/viewvc/*checkout*/fireclipse/trunk/FireclipseTests/WebContent/testXSLT.xsl 
> 
> 
> Note that scripts like these are not run in the stylesheet, but rather 
> they are run while the result page is created. And of course only if the 
> result page contains those elements.

Yes I understood that.  The XML loads, the transformation runs, then its 
a web page.  That's the point that normal Firebug stuff should work.

> 
>>> What it might be is that you're managing to attach eventlisteners to 
>>> the source XML file, i.e. the one before transformation takes place. 
>>> I do think we might (arguably errorously) be firing events at that 
>>> document.
>>
>> I am trying to attach to the *window* before the transformation. The 
>> last point that I can trace is the load of the .xsl file.
> 
> Note that scripts in the .xsl file are not run before the 
> transformation. They are run during the transformation when those result 
> elements are created.

Right, but what window are they created in? Or what happens to the 
window during the transformation besides the document transform?

> 
>> At that point my additions to the window object are still there. The 
>> next time I have control is in the transformed code top-level script.  
>> Then my additions are gone.  (We already decided there were no events 
>> raised by the XSLT engine I think).
> 
> I'm really confused as to what you're actually trying to do. Are you 
> trying to fix the problem that firebug doesn't work well with XSLT pages?

Yes. Specifically Firebug works fine once you get it to look at the 
page. But it did not seem to track the appearance of the page, and XSLT 
messed up Firebug's tracking of other pages.

> 
>>> However I think we're not firing them at the result document, which 
>>> probably is where firebug is attaching its listeners.
>>
>> In my test the listeners that succeed are in the .xsl file. The 
>> window.addEventListener() calls are in the XSLT result and were are 
>> not in the xml file.  The listeners that fail are attached in a 
>> nsiWebProgressListener on a window with a .xml uri before the 
>> transformation.
>>
>> Now "source document" and "result document" sounds interesting. From 
>> my point of view there is only a window, its primary document. Can I 
>> see the source document or result document in javascript code?
> 
> You can't get to the source document from within a webpage. You might be 
> able to get to it from chrome, I don't know. You can try. The result 
> document is what you get when you use 'document' in javascript in the 
> result page.

Yes, but my problem is that the *window* that the result document lives 
in is somehow not the same as the source window. I only have the source 
window to watch. So I can't get the result document because I don't have 
the result window.  Or rather I have event listeners on the source 
window and they appear to get erased.  The result window could be the 
same object, but its contents outside of the document being transformed 
seem to be changed.

> 
> What exactly are you trying to accomplish? What have you tried? What 
> happened when you tried that? I feel like you're trying a lot of things 
> without really knowing what you're testing, so you're drawing wrong 
> conclusions.

Well I was on the wrong track for a while. I did addEventListener() for 
normal web page events and they never got called. So I assumed, 
incorrectly, that the XSLT engine was not raising them.  Now I realize 
that all the normal events appear, but the handler I added must be 
erased.  I think that because I put stuff in the window object (eg 
window.uid) and then look for them in the result.  Gone.

I wish I knew how to give you a simple example that you could see. 
Basically, on a nsIWebProgressListener I do:
   window.addEventListener for DOMContentLoaded
   window.uid = something.
For regular pages, the uid appears and the handler is called. For XSLT, 
the uid is missing and the handler is not called.  Since the handler is 
not called, Firebug cannot know the document completed and does not sync 
its display.

I appreciate your patience,
John.


> 
> / Joans