53118 - certain events bubble that should not according to DOM2 Event handling spec

Status: NEW

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

Description

[Nisheeth Ranjan]

There are certain event types that should not bubble according to the DOM2 Event
Handling spec, but Gecko currently bubbles *all* events (except for load event
on images, which heikki will fix with a patch for a separate bug).

We will plan on fixing this in a future release. In the meantime, for developers
who wish to create content that complies with the intended functioning of the
DOM2 Event Handling spec and works cross-browser with IE, the workaround is to
check whether you're running on Gecko via client sniffing, and insert a
conditional code fork in your JavaScript so that when you're running on Gecko,
you explicitly preventBubbles on the event that really shouldn't bubble in the
first place.

Also, content developers should *not* write content that depends on the current
bubbling of events that should not bubble, as we will fix this bug in a future
release and such code would then break.

When Heikki is done coding for this release, he'll add to this bug report (and
the release notes) a list of the events for which we have this problem.

Comment 1

[Loco]

Updating QA Contact.

Comment 2

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

Events that bubble but should not bubble

The short answer is: all events bubble in Mozilla. There is one exception: the
load event caused by image load does not bubble (this is per the spec).

This means that the following events that should not bubble according to the
specs do bubble in Mozilla, which is wrong:

load   (except when caused by image load)
unload
focus
blur


The above applies to content developers.


XUL developers can generally rely on all events bubbling, but there are certain
events coming from content that are prevented from entering XUL. These are:

load (when caused by image load) (filtered completely)
load                             (filtered in bubbling stage)
unload                           (filtered in bubbling stage)
focus                            (filtered in bubbling stage)
blur                             (filtered in bubbling stage)

Comment 3

[Hixie (not reading bugmail)]

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.

Comment 4

[ekrock's old account (dead)]

Nom. nsbeta1.

Comment 5

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

nsbeta1-, but we'd really want to have this for 1.0.

Comment 6

[Jason Henriksen]

I do not understand this bug.  If the load event does not bubble, how can one
frame know when another is done loading?  I have two frames that need to
interact, so I put a listener on top and wait the the onLoad event.  This works
great in 4.78.  What am I supposed to do in mozilla?  I can't put an 'onLoad
tell the other windows that you don't know about that your're done' method on
every single page I might want to have interaction with.

I could consider having window A attach a listener to window B, but what if I
miss the event?  I would have forever waiting for an even that has already left
town.  

If I don't want on load to bubble, I should pass true as the third parameter. 
If I do want it to bubble, I should pass false.

I admit that I'm not a JavaScript ninja.  Is there any enlightenment about this?

Comment 7

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 8

[Radha on family leave (not reading bugmail)]

I think I know how to fix this bug. Can someone give me a testcase?  It looks
like I have to add a  event handler and these specific events and some prevent
them from bubbling. How do I do that in JS?

Comment 9

[Radha on family leave (not reading bugmail)]

Taking from joki

Comment 10

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

We should also check what IE is doing and consider if we want to fix this or not
based on that.

Comment 11

[Madhur Bhatia]

cc'ing vladimir (default QA contact)

Comment 12

[Vedran Miletic]

retargeting

Comment 13

[timeless]

.

Comment 14

[Boris Zbarsky [:bzbarsky]]

So... what exactly is IE's behavior?  That's the first step to going anywhere on
this bug...

Comment 15

[Hixie (not reading bugmail)]

It is?

Comment 16

[Boris Zbarsky [:bzbarsky]]

In my opinion, yes.  That gives us an idea of what things may or may not break
if we implement this precisely per spec.  Then we decide whether to break them.

Comment 17

[Alex Vincent [:WeirdAl]]

How does XBL anonymous content affect bubbling?  I've yet to really receive a
clear answer on that...

Comment 18

[Boris Zbarsky [:bzbarsky]]

Good question.... Does an event that actually happened on some anonymous content
get dispatched at target on the bound node?  Or what?

Comment 19

[Michael Winter]

As I recently encountered this bug, and no-one's actually followed-up with 
information on IE's behaviour, I thought I'd share a test case (all tests 
occurred on XP). This is what I can deduce from my observations.

IE 6 (SP1)

1) No alert boxes displayed
2) "d4" and "d3" displayed
3) As expected

When the document tree is modified by a listener, propagation stops at that node 
after all registered listeners fire.

In the first phase of the test, the button modifies the document, so there is no 
bubbling at all. In the second phase, the listener on "d3" modifies the 
document, so "d2" doesn't receive the event. In the third phase, no 
modifications occur, so bubbling occurs all the way up to the document root.

Mozilla 1.8a (Build 2004041608):

1) "d4", "d3", "d2", and "d1" displayed
2) As (1)
3) As expected

As the event flow is not predetermined, the listeners are fired on all of the 
elements, meaning that all phases of the test occur on the first invokation.

Opera 7.23 (Build 3227):

1) As expected
2) As expected
3) As expected

This is the only browser I currently have working that behaves as planned.

I hope that's useful in some way.

Comment 20

[Michael Winter]

Attachment: Demonstration of event propagation during document mutation

Comment 21

[Boris Zbarsky [:bzbarsky]]

Michael, that testcase has nothing to do with this bug... This bug is not about
the fact that event propagation doesn't use a snapshot of the DOM, which is what
your testcase tests.

Comment 22

[Michael Winter]

There is a tenuous link (events shouldn't bubble as shown in the test case) but 
in all, you're right: it's not what this bug is about, and I apologise. By the 
time I realised it myself - long after the submission - there was nothing to be 
done except expect a response like yours.

By the way, I can't replicate this bug with v1.8. In fact, I can't attach a load 
listener to body using any of

document.body.onload
document.onload
document.body.addEventListener()
document.addEventListener()

Only using window.onload, window.addEventListener(), or <body ... onload=""> 
functions with Mozilla. All of these are supported by Opera 7.23, and IE 6 
supports document.body.onload.

Comment 23

[Firefox Bug Husbandry Bot]

Bulk priority change, per :mdaly