Last Comment Bug 329514 - Sort out the exact behavior for *LOAD events
: Sort out the exact behavior for *LOAD events
Status: NEW
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on: 234455
  Show dependency treegraph
Reported: 2006-03-06 08:47 PST by Olli Pettay [:smaug]
Modified: 2012-06-05 03:18 PDT (History)
12 users (show)
vladimir: blocking1.9-
reed: wanted1.9+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Olli Pettay [:smaug] 2006-03-06 08:47:24 PST
Comment 1 Olli Pettay [:smaug] 2006-03-06 08:48:13 PST
We should sort out the exact behavior for *LOAD events.
See also
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2006-04-14 21:02:24 PDT
So the current behavior when someone attaches a load listener to the tabbrowser in Firefox is:

1) Capturing listener -- see loads for documents and for <xul:image>s in the tabbrowser.

2) Bubbling listener -- see no load events.

Presumably that's why uses a capturing listener....

Any idea why the load listeners see nothing there?
Comment 3 Olli Pettay [:smaug] 2006-04-17 04:36:09 PDT
(In reply to comment #2)
> Presumably that's why uses a capturing
> listener....

It uses bubbling listener.
window.addEventListener("load", function() { myExtension.init(); }, false);

Comment 4 Nickolay_Ponomarev 2006-04-17 04:52:16 PDT
The bubbling listener is for extension initialization routine - it only needs to run when the chrome window loads. The capturing listener is registered on the parent of gBrowser - and is called for content load events.
Comment 5 Boris Zbarsky [:bz] (still a bit busy) 2006-04-17 08:53:13 PDT
smaug, I meant this part:

      appcontent.addEventListener("load", this.onPageLoad, true);
      messagepane.addEventListener("load", this.onPageLoad, true);

But I've thought about it, and I see what's going on.  Load events don't bubble (for documents too).  That's fine (and fixes bug 196057).  But then the problem is that the the load event for a window is fired on its <browser> (due to the code in nsGlobalWindow::PostHandleEvent) but doesn't propagate from there.  In particular, there's no load event fired on the <tabbrowser> (much less the node the Mozillazine code is messing with).

As I see it, there are two options here:

1)  We could make load events "bubble" up to binding parents (but not other
2)  We could make tabbrowser add load listeners to its browsers and fire a load
    event at itself when those fire.  The problem is getting the right target or 
    originalTarget or whatever in that load event -- the target should arguably
    be the document or window that finished loading.  Do we get that correct
    right now when we re-fire the load on our frame element?

I'm frankly somewhat partial to solution #1; we've discussed something like that before, I think.

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