Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#14729 closed feature (fixed)

support augmenting event object on IE

Reported by: bill Owned by: Kris Zyp
Priority: undecided Milestone: 1.8
Component: Events Version: 1.7.1
Keywords: Cc:
Blocked By: Blocking:

Description

On IE, when an event handler modifies the evt object (by adding an attribute), that modification is lost when the event is bubbled up the DOM tree.

This makes it less pleasant to let native events bubble from widgets. I'd like to decorate the event object with a pointer back to the widget, etc.

I'm not sure if it's practical to support this feature. It seems easy to keep track of modifications to the event object with something like:

var mods = {};
evt = dojo.delegate(evt, mods);

The harder part is detecting when an old event has finished, and you are seeing a new event.

I prototype something at http://jsfiddle.net/cPM85/, which basically clears the mods{} hash when the event bubbles to the document level, or someone calls stopPropagation(). It's assuming that one event always finishes executing before a new one starts, and also doesn't account for events that don't bubble.

There might be other approaches too, such as canceling the native event and replacing it with a custom one.

See also #14728 and #13785.

Change History (3)

comment:1 Changed 8 years ago by Kris Zyp

Your prototype is a good idea. A couple of drawbacks to consider:

  • If an event's propagation is stopped outside of Dojo's custom stopPropagation method (if the user directly set this.cancelBubble = true) then the old event could be substituted in for a later event. This would produce pretty bizarre behavior and be hard to track down.
  • This would introduce a performance regression in <=IE8 since most calls to add a listener would result in two cycles of adding a listener to nodes (the target and the document).

Neither of these issues are really deal breakers for me at least. We could also choose to mitigate these issues by having some opt-in mechanism in the API so that the event caching mechanism is only used when necessary. Or we could require that a certain property is modified to indicate the event has been modified. For example:

   on(node, "click", function(evt){
     evt.modified = true;
     evt.myData = 3;

As far as non-bubbling events, I don't think that is an issue, I believe our current event handling already uses the same event object for all the listeners on a single target/node.

comment:2 Changed 8 years ago by Kris Zyp

Resolution: fixed
Status: newclosed

In [28041]:

Add support for stopImmediatePropagation, fixes #14728
Add support augmenting event objects in IE, fixes #14729 !strict

comment:4 Changed 8 years ago by bill

Milestone: tbd1.8
Note: See TracTickets for help on using tickets.