Re: XSLT processing model in Mozilla

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

> 
> 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.  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).

> 
> 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?


> 
> / Jonas
> 
> John J. Barton wrote:
>> I've started to look at XSLT again in Firebug with FF3. I decided to 
>> try   more experiments and I got some surprising results.
>>
>> First off, XML pages with XSL do indeed raise pageshow, 
>> DOMContentLoaded, load, unload, and pagehide.  That is, if I issue 
>> window.addEventListener() in a top level script in my test.xsl, these 
>> events trigger handlers.
>>
>> But Firebug also adds event listeners for the same events and these 
>> are not triggered. And if I put win.uid = 12345 in Firebug, the top 
>> level script cannot find win.uid.
>>
>> So it is as if the window created for the .xml load which I manipulate 
>> in Firebug before the top-level script runs is erased during the XSLT 
>> step.  Is that possible?
>>
>> Thanks,
>> John.
>>
>> Jonas Sicking wrote:
>>> John J. Barton wrote:
>>>> Jonas Sicking wrote:
>>>>> John J. Barton wrote:
>>>>>> Jonas Sicking wrote:
>>>>>>> The way we do it for transformations done using
>>>>>>> <?xml-stylesheet type="text/xslt" ...?> is as follows:
>>>>>>>
>>>>>>> We parse the source document normally into a DOM, however during 
>>>>>>> this parsing script execution is turned off for the source document.
>>>>>>>
>>>>>>> Simultaneously we load the stylesheet and parse it into an 
>>>>>>> internal compiled format (not a DOM).
>>>>>>>
>>>>>>> Once both the source document and stylesheet is done loading we 
>>>>>>> execute the stylesheet.
>>>>>>>
>>>>>>> Executing the stylesheet builds DOM nodes which once the 
>>>>>>> execution is done is displayed instead of the source document.
>>>>>>
>>>>>> Jonas,
>>>>>>   - are any events raised after execution?
>>>>>
>>>>> You should get a normal 'load' event.
>>>>
>>>> How about pageshow? DOMContentLoaded?
>>>
>>> I think these are not currently fired. This is a bug which would be 
>>> great to get fixed. I believe that if you search bugzilla you can 
>>> find it.
>>>
>>> Please refrain from "i'd like this bug fixed" comments though. We 
>>> already know.
>>>
>>>>>>   - at what point is script execution turned on?
>>>>>
>>>>> script execution is never turned on for the source document. It is 
>>>>> always on for the result document though.
>>>>
>>>> So the first script tag is executed before the next element is 
>>>> added? Or the script engine is activated after the stylesheet has 
>>>> been exhausted but before the 'load' event is raised? Or?
>>>
>>> The script engine is always active, so the <script> element is 
>>> executed as soon as it is inserted. The one difference though is that 
>>> <script> elements that refer to external scripts will not halt 
>>> execution of the stylesheet to wait for the external script to load. 
>>> This means that such element will likely not execute until the 
>>> stylesheet is finished executing.
>>>
>>> / Jonas