Last Comment Bug 109760 - DOMContentLoaded event
: DOMContentLoaded event
Status: VERIFIED FIXED
[HAVE FIX]
:
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: x86 All
: -- enhancement (vote)
: mozilla0.9.7
Assigned To: Johnny Stenback (:jst, jst@mozilla.com)
: Vladimir Ermakov
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-11-12 10:16 PST by Allen Tom
Modified: 2007-09-25 12:21 PDT (History)
3 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Proposed fix, including related leak fix from the trunk... (2.09 KB, patch)
2001-11-26 21:57 PST, Johnny Stenback (:jst, jst@mozilla.com)
peterv: review+
rpotts: superreview+
Details | Diff | Splinter Review
testcase (814 bytes, text/html)
2001-11-29 14:00 PST, lchiang
no flags Details
new testcase (882 bytes, text/html)
2001-11-29 16:16 PST, Heikki Toivonen (remove -bugzilla when emailing directly)
no flags Details
testcase with image onload handler (809 bytes, text/html)
2001-11-29 17:12 PST, Sivakiran Tummala
no flags Details

Description Allen Tom 2001-11-12 10:16:17 PST
The Quick Checkout Form Fill (QCFF) project would like to have an event fired as 
soon as all the html/css/js has been downloaded. When this event is fired, we 
need access to read/write the dom, especially the form elements.

This event NOT wait for the document's images to load before firing.

This event is intented to give QCFF the opportunity to analyze the forms on a 
document, and begin form filling as soon as possible. The "other" browser engine 
forces us to wait until all the document's objects have loaded or timedout. This 
is particularly bad if one of the images is broken or takes a long time to load.

jst has coded up a patch to nsDocument.cpp for us to try out:

Index: content/base/src/nsDocument.cpp
===================================================================
RCS file: /cvsroot/mozilla/content/base/src/nsDocument.cpp,v
retrieving revision 3.336
diff -u -r3.336 nsDocument.cpp
--- nsDocument.cpp      2001/11/02 01:52:44     3.336
+++ nsDocument.cpp      2001/11/10 06:40:31
@@ -1623,6 +1623,19 @@
       i--;
     }
   }
+
+  // Fire a DOM event notifying listeners that this document has been
+  // loaded (excluding images and other loads initiated by this
+  // document).
+  nsCOMPtr<nsIDOMEvent> event;
+  CreateEvent(NS_LITERAL_STRING("Events"),
+              getter_AddRefs(event));
+  if (event) {
+    event->InitEvent(NS_LITERAL_STRING("DOMContentLoaded"), PR_TRUE, PR_TRUE);
+    PRBool noDefault;
+    DispatchEvent(event, &noDefault);
+  }
+
   return NS_OK;
 }
Comment 1 Johnny Stenback (:jst, jst@mozilla.com) 2001-11-12 15:24:07 PST
Taking.
Comment 2 Johnny Stenback (:jst, jst@mozilla.com) 2001-11-12 15:24:47 PST
Really taking.
Comment 3 Allen Tom 2001-11-26 11:38:33 PST
Seems to work great! 
Comment 4 Johnny Stenback (:jst, jst@mozilla.com) 2001-11-26 21:57:03 PST
Created attachment 59287 [details] [diff] [review]
Proposed fix, including related leak fix from the trunk...
Comment 5 Peter Van der Beken [:peterv] 2001-11-27 01:42:11 PST
Comment on attachment 59287 [details] [diff] [review]
Proposed fix, including related leak fix from the trunk...

r=peterv
Comment 6 Allen Tom 2001-11-27 17:41:29 PST
This needs to be checked into the CompuServe branch, Mozilla 0.94
Comment 7 rpotts (gone) 2001-11-27 21:51:00 PST
Comment on attachment 59287 [details] [diff] [review]
Proposed fix, including related leak fix from the trunk...

sr=rpotts@netscape.com
Comment 8 Johnny Stenback (:jst, jst@mozilla.com) 2001-11-27 22:38:18 PST
Fix checked in on the trunk. Waiting for a day or two to check in on the branch.
Comment 9 lchiang 2001-11-29 13:59:59 PST
Siva created a testcase for this bug.  I'm attaching it.  
Comment 10 lchiang 2001-11-29 14:00:42 PST
Created attachment 59743 [details]
testcase
Comment 11 lchiang 2001-11-29 14:01:52 PST
pasting comments from chofmann via email:  "how can we test/make sure it won''t
 turn up regressions elsewhere? and possible side effects on performance?"
Comment 12 Marcia Knous [:marcia - use ni] 2001-11-29 16:12:38 PST
EDT - Embedding friends are pulling tomorrow morning. Please check in to 0.9.4.
Comment 13 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-11-29 16:16:01 PST
Created attachment 59772 [details]
new testcase
Comment 14 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-11-29 16:22:12 PST
Oh, you also want to have onload handlers on the images and record the order in
which all of the loadhandlers fire.
Comment 15 Sivakiran Tummala 2001-11-29 17:12:29 PST
Created attachment 59783 [details]
testcase with image onload handler
Comment 16 Sivakiran Tummala 2001-11-29 17:19:40 PST
Tested on build 2001-11-29-09 trunk, and this bug is fixed on the trunk. The 
DOMContentLoaded event is being fired before the image was loaded, and the input 
text value has been changed.
Comment 17 Johnny Stenback (:jst, jst@mozilla.com) 2001-11-29 23:46:35 PST
Fix checked in on the 094 branch.
Comment 18 Ed 2001-11-30 09:04:49 PST
Too bad that nsIDOMEvent is not a public interface, meaning that it is not 
quite exposed to embedding applications. Recommend to expose it through 
nsIWebProgressListener
Comment 19 Johnny Stenback (:jst, jst@mozilla.com) 2001-11-30 23:11:37 PST
I don't think we need to expose this through nsIWebProgress, in stead we can
simply freeze nsIDOMEventListener, nsIDOMEventTarget, and nsIDOMEvent so that
embedding clients can use those interfaces.
Comment 20 Ed 2001-12-03 12:30:35 PST
Yes, with nsIDOMEventListener, nsIDOMEventTarget, and nsIDOMEvent we are good 
to go.
Comment 21 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-12-05 14:48:03 PST
Marking fixed and adding fixed0.9.4 keyword.
Comment 22 Allen Tom 2001-12-19 12:35:28 PST
For framesets, this event is only fired when the root document is loaded. 

Is there a way to get DOMContentLoaded fired for each frame?



Comment 23 Johnny Stenback (:jst, jst@mozilla.com) 2001-12-20 02:06:05 PST
DOMContentLoaded is fired in every frame as well as in the toplevel
document/frameset. If the toplevel document/frameset needs to know when a frame
in the document is done loading, we'd need a new event for that, something like
DOMFrameContentLoaded. If that's what's needed, then please file a separate bug
on that. Closing again.
Comment 24 Vladimir Ermakov 2002-01-09 14:34:02 PST
Verifying on windows98 2002-01-07-03-trunk and linux 2002-01-04-08-trunk

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