DOMContentLoaded event

VERIFIED FIXED in mozilla0.9.7

Status

()

Core
DOM: Events
--
enhancement
VERIFIED FIXED
16 years ago
10 years ago

People

(Reporter: Allen Tom, Assigned: jst)

Tracking

Trunk
mozilla0.9.7
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [HAVE FIX])

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

16 years ago
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;
 }
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 1

16 years ago
Taking.
(Assignee)

Comment 2

16 years ago
Really taking.
Assignee: joki → jst
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Whiteboard: [HAVE FIX]
Target Milestone: --- → mozilla0.9.7
(Reporter)

Comment 3

16 years ago
Seems to work great! 
(Assignee)

Comment 4

16 years ago
Created attachment 59287 [details] [diff] [review]
Proposed fix, including related leak fix from the trunk...
Comment on attachment 59287 [details] [diff] [review]
Proposed fix, including related leak fix from the trunk...

r=peterv
Attachment #59287 - Flags: review+
(Reporter)

Comment 6

16 years ago
This needs to be checked into the CompuServe branch, Mozilla 0.94

Comment 7

16 years ago
Comment on attachment 59287 [details] [diff] [review]
Proposed fix, including related leak fix from the trunk...

sr=rpotts@netscape.com
Attachment #59287 - Flags: superreview+
(Assignee)

Comment 8

16 years ago
Fix checked in on the trunk. Waiting for a day or two to check in on the branch.

Updated

16 years ago
Keywords: edt0.9.4+

Comment 9

16 years ago
Siva created a testcase for this bug.  I'm attaching it.  

Comment 10

16 years ago
Created attachment 59743 [details]
testcase

Comment 11

16 years ago
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?"
EDT - Embedding friends are pulling tomorrow morning. Please check in to 0.9.4.
Created attachment 59772 [details]
new testcase
Attachment #59743 - Attachment is obsolete: true
Oh, you also want to have onload handlers on the images and record the order in
which all of the loadhandlers fire.

Comment 15

16 years ago
Created attachment 59783 [details]
testcase with image onload handler
Attachment #59772 - Attachment is obsolete: true

Comment 16

16 years ago
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.
(Assignee)

Comment 17

16 years ago
Fix checked in on the 094 branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 18

16 years ago
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 19

16 years ago
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

16 years ago
Yes, with nsIDOMEventListener, nsIDOMEventTarget, and nsIDOMEvent we are good 
to go.
Marking fixed and adding fixed0.9.4 keyword.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Keywords: fixed0.9.4
Resolution: --- → FIXED
(Reporter)

Comment 22

16 years ago
For framesets, this event is only fired when the root document is loaded. 

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



Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 23

16 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 24

16 years ago
Verifying on windows98 2002-01-07-03-trunk and linux 2002-01-04-08-trunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.