390263 - bubbling 'load' handler on <browser> never called

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: testcase

Testcase attached.  Only event handlers attached to the capturing phase of the 'load' event on a content <browser> seem to fire.

Run attached testcase with -chrome (UniversalXPConnect priv request is there for file:// URIs); should see both the capture and bubbling event handler called, instead only the dump from capturing appears.

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

For the record, Fx2 only fires the capturing event as well, so at least this isn't a regression.  bz seemed to think that we fire the capturing phase handlers before any content event handlers, and that we fire bubbling after all the content load handlers -- but my guess is that the load event dispatched to content never bubbles upward to the <browser>?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Hmm.  I'd really expect this to work.  It certainly works for <html:iframe> last I checked... and here the chrome event handler thing should also happen, no?

Comment 3

[Alex Vincent [:WeirdAl]]

I'm betting this is dependent on wantsUntrusted, http://lxr.mozilla.org/seamonkey/source/dom/public/idl/events/nsIDOMNSEventTarget.idl

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Ah, I'm guessing this is because the event is untrusted at that point in the
bubbling phase, since content would've had a chance to modify it... and
wantsUntrusted is implicitly false in my calls to addEventListener.  If this is
the right thing to be looking at, what's the right way to set an event listener
that'll listen for untrusted events from chrome js?  If that's not the problem,
then the original bug stands :)

Comment 5

[Boris Zbarsky [:bzbarsky]]

Ah, looks like we don't force-bubble up to the chrome event handler (I thought we did), and don't fire onload on the frameElement if the window is either chrome or the root of a content tree.

Sucks, but I doubt we can change things here too much....

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/base/nsDocumentViewer.cpp&rev=1.539&mark=942#937

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

So this is IMO, INVALID

Comment 8

[Boris Zbarsky [:bzbarsky]]

Smaug, that doesn't matter here.  The load is fired on the window, which propagates it out to its frameElement (not via DOM bubbling, but by explicitly firing another load event)... but only for content. Not for chrome.  I'm not sure why, and I can accept a wontfix (esp. since it would change the behavior), but the inconsistency bothers me.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

well, ok, when thinking this that way :)
The summary is a bit misleading.
The capturing event handler is called when the event is dispatched to
|window|, but because load doesn't bubble, the bubbling handler isn't called.

Hmm, would anything break if we remove 
if (content && GetParentInternal() && itemType != nsIDocShellTreeItem::typeChrome)
Load event wouldn't anyway propagate to chrome |window|.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Oh, good point!  I bet that's why that code was there: because chrome window onload handlers were firing.  I saw we should remove that special case.  I can't think of anyone watching bubbling load events on <browser> who won't actually want the load event, and the event won't go anywhere else.  (Though it would be cool if I could watch loads on <tabbrowser> to be honest.  But that's a separate issue that we should file on toolkit.)

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Proposed fix

The idea here is to not clear out the JS frame stack if the context being pushed is what's already at that top.  We'd still clear it when pushing a null context, of course.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Er.... wrong bug.  :(

Comment 13

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.