Open Bug 325891 Opened 19 years ago Updated 2 years ago

DOMContentLoaded event not fired in result document of XSLT transformation

Categories

(Core :: XSLT, defect)

Product:
Core
Component:
XSLT
Platform:
x86
Windows XP
Type:
defect

Tracking

()

People

(Reporter: martin.honnen, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted) 

Mozilla since 2002 implements an event named 'DOMContentLoaded' to allow script to access the DOM without needing to wait for the W3C DOM event named 'load' which is only fired after all linked resources like images have been loaded.

The DOMContentLoaded event works flawlessly in a current nightly trunk build (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060203 Firefox/1.6a1) in the test case at:
<http://home.arcor.de/martin.honnen/mozillaBugs/xslt/DOMContentLoaded1.xhtml>
however when trying to listen to that same event in a result document of an XSLT transformation the DOMContentLoad event is not fired:
<http://home.arcor.de/martin.honnen/mozillaBugs/xslt/DOMContentLoadedAfterXSLT1.xml>
Only the load event is fired.

The test case simply applies an XSLT identity transformation to an XHTML document.

This does not seem to be a regression but rather a long standing bug as I see the problem with Mozilla 1.7 and 1.8 too.

Bug was reported in mozilla.dev.tech.xslt.
Does this apply even when going 'back' to an XSLT generated page? Or does the event fire then, just not on the original load?
(In reply to comment #1)
> Does this apply even when going 'back' to an XSLT generated page? Or does the
> event fire then, just not on the original load?

Firefox 1.5 and later have that complete DOM caching mechanism I think which means when navigating back to a page neither DOMContentLoaded nor load are fired again, only the new pageshow event is being fired.

My tests show that DOMContentLoaded is not being fired in XSLT generated XHTML documents, whether you load it first or navigate back.

The test shows an additional flaw for Firefox 1.5.0.1 (but not the trunk build) in that navigating back should fire pageshow again but only does for a static XHTML document, not for the XSLT generated one.

See detailed test results below:

I have made two additional documents to test that, here is the static XHTML document outputting the time when DOMContentLoaded, pageshow, load are fired:
<http://home.arcor.de/martin.honnen/mozillaBugs/xslt/DOMContentLoaded2.xhtml>

Here is the same XHTML document but served as text/xml and with a processing instruction doing an identity transformation to application/xhtml+xml:
<http://home.arcor.de/martin.honnen/mozillaBugs/xslt/DOMContentLoadedAfterXSLT2.xml>

Test with Firefox trunk nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060203 Firefox/1.6a1):

Static XHTML after load shows:

Sun Feb 05 2006 13:42:40 GMT+0100: DOMContentLoaded at [object Window] for [object HTMLDocument]

Sun Feb 05 2006 13:42:40 GMT+0100: load at [object Window] for [object HTMLDocument]

Sun Feb 05 2006 13:42:40 GMT+0100: pageshow at [object Window] for [object HTMLDocument]

Following link and navigating back shows:

Sun Feb 05 2006 13:42:40 GMT+0100: DOMContentLoaded at [object Window] for [object HTMLDocument]

Sun Feb 05 2006 13:42:40 GMT+0100: load at [object Window] for [object HTMLDocument]

Sun Feb 05 2006 13:42:40 GMT+0100: pageshow at [object Window] for [object HTMLDocument]

Sun Feb 05 2006 13:43:20 GMT+0100: pageshow at [object Window] for [object HTMLDocument]

Thus with that build when you navigate back the previous DOM that was cached is shown again and only an additional pageshow event is fired.

Loading XHTML generated by XSLT shows:

Sun Feb 05 2006 13:45:38 GMT+0100: load at [object Window] for [object XMLDocument]

Sun Feb 05 2006 13:45:38 GMT+0100: pageshow at [object Window] for [object XMLDocument]

Following link and navigating back shows:

Sun Feb 05 2006 13:45:38 GMT+0100: load at [object Window] for [object XMLDocument]

Sun Feb 05 2006 13:45:38 GMT+0100: pageshow at [object Window] for [object XMLDocument]

Sun Feb 05 2006 13:46:22 GMT+0100: pageshow at [object Window] for [object XMLDocument]

So DOMContentLoaded is not fired on initial load and when the back button is used to navigate back the event does not appear either, only pageshow is fired once the cached DOM is shown again.


Test with Firefox 1.5.0.1:

Static XHTML:

Sun Feb 05 2006 13:32:28 GMT+0100: DOMContentLoaded at [object Window] for [object HTMLDocument]

Sun Feb 05 2006 13:32:28 GMT+0100: load at [object Window] for [object HTMLDocument]

Sun Feb 05 2006 13:32:28 GMT+0100: pageshow at [object Window] for [object HTMLDocument]

Following link and then going back results in:

Sun Feb 05 2006 13:32:28 GMT+0100: DOMContentLoaded at [object Window] for [object HTMLDocument]

Sun Feb 05 2006 13:32:28 GMT+0100: load at [object Window] for [object HTMLDocument]

Sun Feb 05 2006 13:32:28 GMT+0100: pageshow at [object Window] for [object HTMLDocument]

Sun Feb 05 2006 13:38:21 GMT+0100: pageshow at [object Window] for [object HTMLDocument]


So for the static XHTML Firefox 1.5.0.1 behaves as the trunk build, it caches the DOM, shows it back and fires a new pageshow event then.

XSLT generated XHTML:

Sun Feb 05 2006 13:35:04 GMT+0100: load at [object Window] for [object XMLDocument]

Sun Feb 05 2006 13:35:04 GMT+0100: pageshow at [object Window] for [object XMLDocument]

Following link and then going back results in:

Sun Feb 05 2006 13:35:04 GMT+0100: load at [object Window] for [object XMLDocument]

Sun Feb 05 2006 13:35:04 GMT+0100: pageshow at [object Window] for [object XMLDocument]

So with Firefox 1.5.0.1 when navigating back to the XSLT generated document the pageshow event is not fired. load and DOMContentLoad are not fired either.


Test with Mozilla 1.7 and normal XHTML document:

Sun Feb 05 2006 13:24:54 GMT+0100: DOMContentLoaded at [object Window] for [object HTMLDocument]

Sun Feb 05 2006 13:24:54 GMT+0100: load at [object Window] for [object HTMLDocument]

Following link and then going back results in:

Sun Feb 05 2006 13:26:19 GMT+0100: DOMContentLoaded at [object Window] for [object HTMLDocument]

Sun Feb 05 2006 13:26:19 GMT+0100: load at [object Window] for [object HTMLDocument]

Test with XHTML document generated by an XSLT identity transformation:

Sun Feb 05 2006 13:28:50 GMT+0100: load at [object Window] for [object XMLDocument]

Following link and then going back results in:

Sun Feb 05 2006 13:30:08 GMT+0100: load at [object Window] for [object XMLDocument]

So with Mozilla 1.7 the load event is fired in XSLT generated XHTML when the page is being loaded initially and when navigating back, but DOMContentLoaded is missing in both cases.
Changing URL of test case to one that use an identity transformation not copying the <?xml-stylesheet?> pi nodes to avoid potential recursion in earlier test case.

Mozilla's behavior is the same with both test cases so nothing changes in terms of the bug reported.
URL: http://home.arcor.de/martin.honnen/mo... → http://home.arcor.de/martin.honnen/mo...
So we're firing DOMContentLoaded for the original XML, but not for the transform result, basically?

We could probably fire it when inserting the transformed DOM, if that's the behavior we want...
Yeah, that's what I think we should do. Additionally I don't think we should fire it for the original XML source.
Seems reasonable.  Do we have anyone who can write this up in time for 1.9?
This is easy, we should be able to find someone.
Flags: blocking1.9?
Not a blocker.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Keywords: helpwanted
Isn't this fixed now. I do get DOMContentLoaded with XSLT, using my 
own test and using Martin's tests.
Would be great to know what has fixed this.
smaug, see comment 4.
It would also be great to get pageshow and pagehide events as appropriate.
Bz, the behavior has changed since 1.8. Using the testcases
I don't see any DOMContentLoaded events in 1.8, but in 1.9 those are
there.
Sure.  I'm not going to even worry about 1.8.  I tested with 1.9, getting behavior as per comment 4.
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
Assignee: xslt → nobody
QA Contact: keith → xslt
Is this bug abandoned?
Re comment 4
What's the point to firing DOMContentLoaded for the original XML having xml-stylesheet instruction? The corresponding DOM object has too short lifetime.
I suggest to fire DOMContentLoaded when inserting the transformed DOM in such case.
Seems like this bug is the cause of http://bugs.jquery.com/ticket/13193
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.