55414 - Filter out frame loads in navigator.js(?)

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P3)

Description

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This grew out of bug 51211.

In navigator.js, event listeners are added to respond to page load events:
contentArea.addEventListener("load", UpdateBookmarksLastVisitedDate, true);
contentArea.addEventListener("load", UpdateInternetSearchResults, true);
contentArea.addEventListener("load", checkForDirectoryListing, true);
contentArea.addEventListener("load", getContentAreaFrameCount, true);
contentArea.addEventListener("load", postURLToNativeWidget, true);

- Do all these functions need to be fired for each frame's "load" event?

------- Additional Comments From Tim Hill 2000-09-22 16:31 -------

What about the load event for frames?  I suggest that all the load handlers be
replaced with a single handler which calls them.  Then you can just add:
if (e.target == window._content.document)
to filter out the load events.  This will filter out the individual frame loads
as well.

A patch does this and some other crap is:

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=15371

------- Additional Comments From Heikki Toivonen 2000-09-22 18:04 -------

The second patch is to navigator.js. It moves all the load event handlers into a
new function which is now the only registered event listener. I do not have the
stats yet how much this saves in time.

I also added the filter Tim Hill suggested. It does indeed filter out the frame
load events (I presume) as well. For example, I put a counter to see how many
events were filtered and on http://developer.netscape.com we filter two events.
However, I do not know if this is safe. Anyone know if the functions in
question would in fact be interested in frame loads as well?

------- Additional Comments From Heikki Toivonen 2000-10-02 18:44 -------

4. It has been identified that also frame load events travel to the chrome, and
this is causing slight performance problems as well as search sidebar reloads.
This has also been addressed in the second patch. I do not know if something is
depending on the frame load events so I would consider this a high risk change
unless proven otherwise. I think the gain is minimal.

Comment 1

[Heikki Toivonen (remove -bugzilla when emailing directly)]

This was fixed along with bug 55413.

Comment 2

[sairuh (rarely reading bugmail)]

rubberstamp vrfy from the branch perspective.

Comment 3

[sairuh (rarely reading bugmail)]

...and rubberstamp vrfy from the trunk pov.