In order to call this method, you'd have to access it via event.nativeEvent.stopImmediatePropagation()
: https://developer.mozilla.org/en-US/docs/Web/API/Event/stopImmediatePropagation
It'd be awesome if this was supported on event
itself. I did see a prior issue for this, but it was for a use case that sIP wasn't required for.
For a specific use case: if you want to kill hover events for touch input, onTouchStart
will trigger onMouseOver
and stopImmediatePropagation
cancels that internal cascade.
I think sIP method on the Synthetic even would just prozy to event.nativeEvent.stopImmediatePropagation
since there isn't anything in the Synthetic event system that would change or need to be implemented, given that components only ever have one handler per event anyway. I wouldn't be opposed to adding it as a convenience but I do think it hides the fact that sIP isn't supported over all React's browsers (though maybe it is now that IE8 is gone)
if you want to kill hover events for touch input, onTouchStart will trigger onMouseOver and stopImmediatePropagation cancels that internal cascade.
Could you please provide me with an example that demonstrates this?
@gaearon , I have a similar problem. I use event.nativeEvent.stopImmediatePropagation() to prevent the rootClose event (react bootstrap) on a popover that has a dropdown. But in my tests I have the following error:
e.nativeEvent.stopImmediatePropagation is not a function
there is even a solution, but there are many tests to replicate such a solution.
the error is caused basically by the click simulation. I think if I had a synthetic event for the same it would be interesting.
Note: My popover is customized over the popup of the react bootstrap and also the dropdown (which renders the items in the body of the document)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.
Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!
Can we this get reopened?
What is your problem with the issue, @Bosch-Eli-Black ?
@mensonones For me, it was nothing special. I just tried to call event.stopImmediatePropagation()
and was slightly surprised to find that it didn't work :)
I concur with the above. The documentation for SyntheticEvent states:
It has the same interface as the browser’s native event, including stopPropagation() and preventDefault(), except the events work identically across all browsers.
Not having stopImmediatePropagation
on it violates the promise that the interface is the same.
If this won't be fixed, at least fix the docs to stop claiming that the interface is the same when it's not.
@gaearon
Please, correct me if I'm wrong, but it seems that the biggest problem here is that native events aren't actually attached to the individual elements, but rather to the root document. You can see this by comparing event.currentTarget
(React element) and event.nativeEvent.currentTarget
(null
).
The currentTarget read-only property of the Event interface identifies the current target for the event, as the event traverses the DOM. It always refers to the element to which the event handler has been attached.
— https://developer.mozilla.org/en-US/docs/Web/API/Event/currentTarget
When you do document.addEventListener()
, event.currentTarget
is null
.
ReactDOM will pass the synthetic events down to the individual handlers you attached to React elements. So, calling event.nativeEvent.stopImmediatePropagation()
there would actually prevent any subsequent event of the same type from happening on the document, and not on the element with the synthetic event handler.
If that's correct, event.nativeEvent.stopImmediatePropagation()
should almost never be used. And I don't think there's an easy way to support sIP on synthetic events unless ReactDOM attaches the native event to the actual element that received the event prop.
That's true enough, but in our case we fully understood that and that's exactly what we wanted (for reasons that are too specific to be worth elaborating, but it involved avoiding a refactor in the short term). We still suffered from misleading documentation even though we mostly understood the consequences of what we were trying to do.
Most helpful comment
I concur with the above. The documentation for SyntheticEvent states:
Not having
stopImmediatePropagation
on it violates the promise that the interface is the same.