Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

component events should mask event propagation. #4059

Open
mhevery opened this issue Sep 8, 2015 · 13 comments
Open

component events should mask event propagation. #4059

mhevery opened this issue Sep 8, 2015 · 13 comments
Labels
area: core Issues related to the framework runtime core: event listeners core: inputs / outputs P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent state: confirmed type: bug/fix
Milestone

Comments

@mhevery
Copy link
Contributor

mhevery commented Sep 8, 2015

@Component({
  selector: 'my-component'
  events: ['change']
})
@View({
  template: '<input (change)="...">'
})
class MyComponent {
} 

The above code creates an issue. It conflates the change event from the MyComponent with the bubbling change event from the <input>.

The correct behavior is that the change event which is part of the components should filter out the DOM change events. Otherwise

<my-component (change)="doSomething($event)">

will sometimes get the $event from the MyComponent and sometimes from the input event.

@mhevery mhevery added this to the alpha-38 milestone Sep 8, 2015
@naomiblack naomiblack modified the milestones: alpha-38, alpha-39 Oct 4, 2015
@IgorMinar IgorMinar modified the milestones: alpha-39, alpha-40, alpha-42, alpha-41 Oct 5, 2015
@mhevery mhevery removed this from the alpha-45 milestone Oct 27, 2015
@zackarychapple
Copy link
Contributor

Is this getting added back to a milestone? Ran into some issues around this the other day.

@ericmartinezr
Copy link
Contributor

A user had the same issue in SO (the output name was renamed in the question, but initially matched the submit event from form)

devversion added a commit to devversion/material2 that referenced this issue May 27, 2016
* Currently the change event of the visual hidden inputs will bubble up and emit its event object to the component's `change` output.

This is currently an issue of Angular 2
- See angular/angular#4059

To prevent the events from bubbling up, we have to stop propagation on
change.

Fixes angular#544.
devversion added a commit to devversion/material2 that referenced this issue May 27, 2016
* Currently the change event of the visual hidden inputs will bubble up and emit its event object to the component's `change` output.

This is currently an issue of Angular 2
- See angular/angular#4059

To prevent the events from bubbling up, we have to stop propagation on
change.

Fixes angular#544.
devversion added a commit to devversion/material2 that referenced this issue May 27, 2016
* Currently the change event of the visual hidden inputs will bubble up and emit its event object to the component's `change` output.

This is currently an issue of Angular 2
- See angular/angular#4059

To prevent the events from bubbling up, we have to stop propagation on
change.

Fixes angular#544.
jelbourn pushed a commit to angular/components that referenced this issue May 27, 2016
* fix(): visual hidden inputs should not bubble change event

* Currently the change event of the visual hidden inputs will bubble up and emit its event object to the component's `change` output.

This is currently an issue of Angular 2
- See angular/angular#4059

To prevent the events from bubbling up, we have to stop propagation on
change.

Fixes #544.
@Ulrikop
Copy link

Ulrikop commented Jul 10, 2018

Would be cool to see a overwrite support for events, so that a intuitive usage is possible for custom event behavior.

@splincode
Copy link
Contributor

@mhevery Is the issue relevant?

@foxx9
Copy link

foxx9 commented Sep 12, 2018

I got caught using a (select) event emitter. ( I think a lot of people could do that "mistake" creating custom component).
Here is an example of the issue, (with (select) or(submit) emitters ):

https://stackblitz.com/edit/angular-playground-whycgq?file=app%2Fhello-framework%2Fhello-framework.component.html

So I guess it would be nice to see this as a compilation error

@Lonli-Lokli
Copy link

Does new labels mean that smth might be changed to make this work?

@jelbourn jelbourn added the P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent label Oct 1, 2020
@ngbot ngbot bot modified the milestones: needsTriage, Backlog Oct 1, 2020
@AndreasHae
Copy link

Any update on this? This is causing major pain for us because it makes our custom button component prone to misuse (using the native click event instead of our own, which leads to e.g. disabled state being ignored).

@mberrezak
Copy link

If I create a custom Button Component and define my own (click) event handler, the button click event fires twice. There should be a way to overwrite it.

@stevendarby
Copy link

@JoostK Wow, so this has been an issue for a while!

Wouldn't it be good to document this somewhere? As suggested here... #49114 (comment)

Or add some kind of compiler warning or error?

What is the full list of names to avoid using?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: core Issues related to the framework runtime core: event listeners core: inputs / outputs P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent state: confirmed type: bug/fix
Projects
None yet
Development

No branches or pull requests