Open Bug 53118 Opened 23 years ago Updated 5 months ago

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

Categories

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

Product:
Core
Component:
DOM: Events
Type:
defect

Tracking

()

People

(Reporter: nisheeth_mozilla, Unassigned)

References

Details

(Whiteboard: relnote-devel)

Attachments

(1 file)

Demonstration of event propagation during document mutation
4.52 KB, text/html
Details 
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.
Keywords: relnote
Target Milestone: --- → Future
Updating QA Contact.
QA Contact: janc → lorca
Whiteboard: relnote-devel
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)

Reassigning QA Contact for all open and unverified bugs previously under Lorca's
care to Gerardo as per phone conversation this morning.
QA Contact: lorca → gerardok
Nom. nsbeta1.
Keywords: nsbeta1
nsbeta1-, but we'd really want to have this for 1.0.
Component: Event Handling → DOM Events
Keywords: nsbeta1 → nsbeta1-
Target Milestone: Future → mozilla1.0
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?

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)
Target Milestone: mozilla1.0 → mozilla1.0.1
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?
Taking from joki
Assignee: joki → radha
We should also check what IE is doing and consider if we want to fix this or not
based on that.
cc'ing vladimir (default QA contact)

retargeting
Target Milestone: mozilla1.0.1 → Future
.
Assignee: radha → events
QA Contact: gerardok → ian
Target Milestone: Future → ---
Keywords: relnote
Depends on: 234455
So... what exactly is IE's behavior?  That's the first step to going anywhere on
this bug...
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.
How does XBL anonymous content affect bubbling?  I've yet to really receive a
clear answer on that...
Good question.... Does an event that actually happened on some anonymous content
get dispatched at target on the bound node?  Or what?
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.
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.
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.
Assignee: events → nobody
QA Contact: ian → events
Bulk priority change, per :mdaly
Priority: P3 → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.