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

React onChange events not bubbling up on unmount #13459

Closed
jpkempf opened this issue Aug 22, 2018 · 6 comments
Closed

React onChange events not bubbling up on unmount #13459

jpkempf opened this issue Aug 22, 2018 · 6 comments
Labels

Comments

@jpkempf
Copy link

jpkempf commented Aug 22, 2018

Do you want to request a feature or report a bug?

I'm reporting a bug.

What is the current behavior?

When attaching an onChange handler to a JSX element, if calling this handler leads to the element being unmounted, then the onChange event never bubbles up in the DOM. This means you can't listen to it on the document, or basically on anything else than the element itself.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.

Example code here: https://codesandbox.io/s/qkr8j85z8j
Try it out here: https://qkr8j85z8j.codesandbox.io

Open the console and click around a bit. You will notice that the single checkbox that never changes it's position triggers both onClick and onChange listeners whereas the other checkboxes that get moved between lists only trigger onClick events.

What is the expected behavior?

I would expect the onChange event to be handled in the same way as the onClick event.

Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?

Tested under these conditions:

  • React 16.3.x and 16.4.x.
  • MacOS 10.13.6
  • Opera 54, Firefox Dev Edition 62, Chrome Canary 70

Behaviour has not changed between versions.

@softberry
Copy link

Events fired in an order. Although it is just a recommendation, click event should be fired before change event.
As you try to remove a DOM element with a click action, and then place it again to DOM, change event will be ignored as at the moment of event firing that element is not a part of Document DOM.

I wrote your sample once again as vanilla. Try this https://codesandbox.io/s/qrp55omvj on Safari and Chrome and Firefox. My current browser Safari on MAC fires change and click but Chrome fires only click for the dynamically generated checkboxes.
Chromes behavior is actually expected behavior, as change event should occur result of click event and it should be fired afterwards.

@philipp-spiess
Copy link
Contributor

I think the unexpected behavior and the difference to native elements is caused by the fact that React listens on click events to trigger synthetic onChange events. We do this for better cross-browser support but this behavior is subject to change (#10830).

One thing you can try to work around this by attaching native event listeners for the change event and trigger the DOM update inside this listener.

@jpkempf
Copy link
Author

jpkempf commented Aug 23, 2018

Thanks for the feedback! It sounds like my best bet at the moment is to await the outcome of #10830.

If I remove the onChange prop from the element and try to use native onChange listeners instead, the element would no longer be a controlled input, which would also be problematic. Our workaround at the moment is to trigger and listen for onClick events instead in cases where onChange would not bubble up. (This happens in an external script outside of React that exists for, sigh, tracking purposes.)

@vinay72
Copy link

vinay72 commented Sep 25, 2018

You have created onChange event handler with a id and onClick event handler with directly printing by using Console.

@stale
Copy link

stale bot commented Jan 10, 2020

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.

@stale stale bot added the Resolution: Stale Automatically closed due to inactivity label Jan 10, 2020
@stale
Copy link

stale bot commented Jan 19, 2020

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!

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

No branches or pull requests

5 participants