Incorrect event.stopPropogation() behavior

[stsvilik]

In DOM event.stopPropogation will prevent event from bubbling upward, but if multiple event handlers assigned to the same Node it will execute them all. In Angular, $emit method executes event handler until very first event.stopPropogation() is called and then stops execution of all other handlers residing on the same scope. I believe that $emit method should go through every handler of it's own scope and stop propagation only for $parent scope further up.

This is an easy one-line change in $rootScope.js all you need to do is move the line that checks for stopPropogation to the end of the do loop where scope is changed to sope.$parent.

[perldork]

So I actually like that Angular does cancel all events - that seems more intuitive to me - but that said:

@hourback and I looked into this a little - stsvillk's request would make event propagation canceling conform to the W3C standard's definition of what stop propagation should do:

http://www.w3.org/TR/DOM-Level-2-Events/events.html

From section 1.2.3:

"Any event handler may choose to prevent further event propagation by calling the stopPropagation method of the Event interface. If any EventListener calls this method, all additional EventListeners on the current EventTarget will be triggered but bubbling will cease at that level. Only one call to stopPropagation is required to prevent further bubbling."

So the trade off here is that people used to jQuery's behavior or base javascript DOM behavior get something different - but Angular users get something more intuitive.

Maybe there could be some kind of switch or option to make this event behave like the DOM API for people who want that? Maybe an optional argument to stopPropagating() even?

Especially since it is just a few line change as you suggest.

[stsvilik]

I am not sure how many Angular users have actually faced this issue (a rare case I must say), but in my case it causes a problem. My scenario is revolved around nested directives where a parent tag directive listens to events from a child tag directive. I would like to stop bubbling at the parent (for obvious reasons). In addition to that I do have several event listeners that are subscribed on the parent tag and they're physically located in different controllers (think composite coding, where I use a plug-in like approach to engage more than one controller per scope). I expect all handlers to be engaged since they are essentially siblings, but current behavior prevents me from doing that. So the "ugly" hack around it is to use "preventDefault" with checking if defaultPrevented is true.

[stsvilik]

How about we add stopImmediatePropagation - like in jQuery?

[perldork]

That sounds good - you think that would be easier for users than adding a
parameter that would change the behavior of the cureent call? On the one
hand a new name dies mean a more explicit call that states intention, on
the other hand it might be harder for users to find and ye two behaviors
are very closely related ....

On Monday, September 2, 2013, Sam Tsvilik wrote:

How about we add stopImmediatePropagation - like in jQuery?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3564#issuecomment-23671725
.

[stsvilik]

I think that Angular did not just came out of nowhere brewed in total isolation. By no means does it (Angular) anticipate developers being first-timers to say jQuery or plain DOM. For these reasons I would vote for something that at least resembles another still prominent framework. Introducing a stopImmediatePropagation method will not only state the intent but will also ensure faster adoption due to similarity.

[perldork]

Sounds reasonable to me! You going to fork and create a pull request?

On Tuesday, September 3, 2013, Sam Tsvilik wrote:

I think that Angular did not just came out of nowhere brewed in total
isolation. By no means does it (Angular) anticipate developers being
first-timers to say jQuery or plain DOM. For these reasons I would vote for
something that at least resembles another still prominent framework.
Introducing a stopImmediatePropagation method will not only state the
intent but will also ensure faster adoption due to similarity.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3564#issuecomment-23690229
.

[stsvilik]

Yes, my original fix is already pending for 1.2-rc2, so once it is clear I will add a 'new feature'.

[stsvilik]

Good news - original fix for stopPropagation made it in.

[perldork]

Awesome!

On Wednesday, October 9, 2013, Sam Tsvilik wrote:

Good news - original fix for stopPropagation made it in.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3564#issuecomment-25945475
.

[mgol]

Is this resolved?

[yordis]

+1

[Narretz]

This was fiyed way back in 47f7bd7