#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 )
I've encountered some features of dojo/on that might be bugs but need verifying if this is expected behaviour.
- 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.
- 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.
- 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)
Change History (6)
Changed 9 years ago by
Attachment: | test_case_1.html added |
---|
Changed 9 years ago by
Attachment: | test_case_2.html added |
---|
comment:1 Changed 9 years ago by
Description: | modified (diff) |
---|
comment:2 Changed 9 years ago by
comment:3 follow-up: 4 Changed 9 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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 Changed 9 years ago by
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.
Replying to jamesthomas:
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.
Looks to me like both your handlers are on the same node (named "elem").
Agreed, it should definitely be in http://docs.dojocampus.org/dojo/on.