Repository navigation
Document the order of Splattributes, {{on}} modifier and component event handlers #17877
Description
Activity
@simonihmig do you want to work on this one too?
This one is [BUGFIX canary] only, the feature was added after the beta branch point.
/cc @cibernox
do you want to work on this one too?
I can do it, but probably only more towards the end of the week...
My gut feeling is that the component’s handler should fire first and given the option to cancel it.
Agree on the order. Not sure about the cancelation.
Currently returning false means we do
event.stopPropagation()(or look intoevent.cancelBubblewith the recent changes to see if the user calledevent.stopPropagation()), and prevent the event to bubble up within our own custom bubbling up implementation.But here we are dealing with the case that we have multiple listeners on the same element, which
event.stopPropagation()does not cancel.event.stopImmediatePropagation()would do that. But not sure if returning false should havestopImmediatePropagation()semantics? And when the user has calledstopImmediatePropagation(), we have no way to find that out, as there seems no equivalent ofcancelBubblefor that case, AFAICT.So not really sure if we can/should allow event cancelation for all the listeners of the same element here? Which is really ironic, as this was exactly the example I brought up as a "dangerous" thing during the RFC process! 🤷♂️😂
But not sure if returning false should have
stopImmediatePropagation()semantics?I think it should not.
return falseis modeled after the jQuery semantics, which I believe isevent.stopPropagation()notevent.stopImmediatePropagation().And when the user has called stopImmediatePropagation(), we have no way to find that out, as there seems no equivalent of cancelBubble for that case, AFAICT.
That's a good point 🤔
So not really sure if we can/should allow event cancelation for all the listeners of the same element here?
I don't "not allowing" it is not really an option, I think the main decision is whether the action handlers get run before or after the component handler. If it's after, then
stopPropagation===stopImmediatePropagation, so that's a bit easier for us. Maybe that's our only option anyway?The
{{on ...}}thing your brought up in the RFC actually has an even worse problem – because it usesaddEventListeneron the underlying element, it will not go through theEventDispatcherand so it will always fire first. But that is a general problem anyway, you can observe that difference by passing{{on ...}}and{{action ...}}on a regular element.I think the window for fixing this has flown. Probably the best we can do now is document what order they do fire in.
@kategengler I opened #21408 for #17877. I didn’t document a specific firing order because I couldn’t find test coverage for the same-element case, so I kept it as a conservative legacy note. Does that still seem useful, or would you prefer exact ordering documented?
- changed the title
[-]Splattributes, {{action}} modifier and component event handlers[/-][+]Splattributes, {{on}} modifier and component event handlers[/+]on Jun 22, 2026 I've updated the title to reflect tha the
actionmodifier has been replaced withon. I do believe documenting the order would be a good thing to do.- changed the title
[-]Splattributes, {{on}} modifier and component event handlers[/-][+]Document the order of Splattributes, {{on}} modifier and component event handlers[/+]on Aug 7, 2026
See #17874 (comment)
As part of the fix we need to decide which one fires first, since it was not specified in the RFC. My gut feeling is that the component’s handler should fire first and given the option to cancel it.