Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#13885 closed defect (wontfix)

dojo/on - cancelling events and firing order

Reported by: James Thomas Owned by:
Priority: high Milestone: tbd
Component: Core Version: 1.7.0b1
Keywords: Cc:
Blocked By: Blocking:

Description (last modified by James Thomas)

I've encountered some features of dojo/on that might be bugs but need verifying if this is expected behaviour.

  1. Cancelling events using dojo.stopEvent doesn't work. In test_case_1.html, I've attached two event handlers and the first one fired calls dojo.stopEvent. However, the second event is still fired.
  1. Attachment order of events dictates order they are fired in. In test_case_2.html, the parent element event handler is fired before the child element's. If I swap round the attachment ordering, I see the reverse. The behaviour seen with dojo.connect would result in the child event handler firing first, regardless of the attachment order.
  1. Using event delegation assumes "dojo/query" available. I hit a problem recently trying to use event delegation when I hadn't externally required the dojo/query module. Can this be documented somewhere?

This was tested against 1.7.0b5 using Chrome on Mac OS X.

Attachments (2)

test_case_1.html (862 bytes) - added by James Thomas 8 years ago.
test_case_2.html (830 bytes) - added by James Thomas 8 years ago.

Download all attachments as: .zip

Change History (6)

Changed 8 years ago by James Thomas

Attachment: test_case_1.html added

Changed 8 years ago by James Thomas

Attachment: test_case_2.html added

comment:1 Changed 8 years ago by James Thomas

Description: modified (diff)

comment:2 in reply to:  description Changed 8 years ago by bill

Replying to jamesthomas:

  1. Cancelling events using dojo.stopEvent doesn't work. In test_case_1.html, I've attached two event handlers and the first one fired calls dojo.stopEvent. However, the second event is still fired.

I thought dojo.stopEvent() would (a) stop propagation and (b) prevent the default action (ex: submitting the form). In your test case, you aren't testing the default action, and both your handlers are on the same node (called "elem"), so I wouldn't expect stopEvent() to have any effect.

  1. Attachment order of events dictates order they are fired in. In test_case_2.html, the parent element event handler is fired before the child element's. If I swap round the attachment ordering, I see the reverse. The behaviour seen with dojo.connect would result in the child event handler firing first, regardless of the attachment order.

Looks to me like both your handlers are on the same node (named "elem").

  1. Using event delegation assumes "dojo/query" available. I hit a problem recently trying to use event delegation when I hadn't externally required the dojo/query module. Can this be documented somewhere?

Agreed, it should definitely be in http://docs.dojocampus.org/dojo/on.

comment:3 Changed 8 years ago by Kris Zyp

Resolution: wontfix
Status: newclosed

I added a note about dojo/query to the docs. And like Bill said, event delegation works based on event listening at the parent, so we can't really doing about this unless we were to try to completely supplant the entire event listening process in the browser, which would almost certainly have significant performance and code size problems.

comment:4 in reply to:  3 Changed 8 years ago by James Thomas

Replying to kzyp:

I added a note about dojo/query to the docs. And like Bill said, event delegation works based on event listening at the parent, so we can't really doing about this unless we were to try to completely supplant the entire event listening process in the browser, which would almost certainly have significant performance and code size problems.

Thanks for looking at this Kris & Bill, I had some incorrect assumptions about the usage of dojo/on, thanks for explaining.

Note: See TracTickets for help on using tickets.