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

stopPropagation does not stop propagation to listeners added with Gator #21

Open
lazd opened this issue Nov 11, 2014 · 4 comments
Open

Comments

@lazd
Copy link

lazd commented Nov 11, 2014

Basically, calling stopPropagation should prevent other delegated listeners further up the DOM from being called, but it doesn't. See the Fiddle here.

Furthermore, listeners added with addEventListener are still called because the actual call to stopPropagation happens at the level of the root element, stopping propagation above it, but not above the child element where the user called stopPropagation at, see this Fiddle for an example. This is non-trivial to solve, so it should at least be documented. Note that jQuery exhibits the same behavior (but does correctly stop propagation to other listeners added further up the DOM).

@lazd lazd changed the title stopPropagation does not not propagation to listeners added with Gator stopPropagation does not stop propagation to listeners added with Gator Nov 11, 2014
@ccampbell
Copy link
Owner

I didn't look too closely at the fiddle, but this is definitely a use case I tested when building Gator. We use it in places on the vimeo player too. Is this something specific to do with mixing Gator listeners with regular listeners? I am pretty sure if you apply all with Gator it works correctly.

@lazd
Copy link
Author

lazd commented Nov 11, 2014

I'm afraid not, here's a version of the Fiddle without regular listeners.

I updated the original Fiddle links in the issue body to be a little more clear.

@ccampbell
Copy link
Owner

Okay, so it seems it is actually dependent on the order the events are bound.

I updated the jsfiddle: http://jsfiddle.net/920fLt1d/9/ (you have to click the inner square now).

You can see it is working there as long as you bind the less specific events later on. Obviously that is not ideal. I'm going to see if there is an easy way to handle this internally.

@lazd
Copy link
Author

lazd commented Nov 11, 2014

Ah interesting. Yeah, the behavior is incorrect regardless, order should not matter in this scenario. It should be a quick fix, I just wanted to report it so it's tracked. Cheers!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants