Last Comment Bug 325891 - DOMContentLoaded event not fired in result document of XSLT transformation
: DOMContentLoaded event not fired in result document of XSLT transformation
Status: NEW
: helpwanted
Product: Core
Classification: Components
Component: XSLT (show other bugs)
: Trunk
: x86 Windows XP
: -- normal with 13 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
http://home.arcor.de/martin.honnen/mo...
: 395132 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-04 08:55 PST by Martin Honnen
Modified: 2015-02-05 12:24 PST (History)
19 users (show)
jst: blocking1.9-
reed: wanted1.9+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Martin Honnen 2006-02-04 08:55:22 PST
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.
Comment 1 Jonas Sicking (:sicking) 2006-02-04 11:34:05 PST
Does this apply even when going 'back' to an XSLT generated page? Or does the event fire then, just not on the original load?
Comment 2 Martin Honnen 2006-02-05 05:00:50 PST
(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.
Comment 3 Martin Honnen 2006-02-06 07:01:23 PST
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.
Comment 4 Boris Zbarsky [:bz] 2007-06-15 11:28:57 PDT
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...
Comment 5 Jonas Sicking (:sicking) 2007-06-15 12:04:17 PDT
Yeah, that's what I think we should do. Additionally I don't think we should fire it for the original XML source.
Comment 6 Boris Zbarsky [:bz] 2007-06-15 22:30:07 PDT
Seems reasonable.  Do we have anyone who can write this up in time for 1.9?
Comment 7 Jonas Sicking (:sicking) 2007-06-15 23:21:30 PDT
This is easy, we should be able to find someone.
Comment 8 Johnny Stenback (:jst, jst@mozilla.com) 2007-07-12 16:48:23 PDT
Not a blocker.
Comment 9 Olli Pettay [:smaug] 2007-07-13 11:48:20 PDT
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.
Comment 10 Boris Zbarsky [:bz] 2007-07-13 11:52:24 PDT
smaug, see comment 4.
Comment 11 Jonas Sicking (:sicking) 2007-07-13 12:00:47 PDT
It would also be great to get pageshow and pagehide events as appropriate.
Comment 12 Olli Pettay [:smaug] 2007-07-13 14:16:48 PDT
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.
Comment 13 Boris Zbarsky [:bz] 2007-07-13 14:51:15 PDT
Sure.  I'm not going to even worry about 1.8.  I tested with 1.9, getting behavior as per comment 4.
Comment 14 aaronr 2007-09-06 10:02:14 PDT
*** Bug 395132 has been marked as a duplicate of this bug. ***
Comment 15 Anton Kochkov 2013-07-07 03:22:12 PDT
Is this bug abandoned?
Comment 16 Ruvim Pinka 2013-08-29 14:03:39 PDT
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.
Comment 17 Mike Taylor [:miketaylr] 2013-10-08 13:30:13 PDT
Seems like this bug is the cause of http://bugs.jquery.com/ticket/13193

Note You need to log in before you can comment on or make changes to this bug.