-
Notifications
You must be signed in to change notification settings - Fork 46.2k
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
Bug: (17.0.0-rc.0) Event propagation through portals is inconsistent #19608
Comments
Thanks for reporting! |
I've investigated the issue and figured out why this happens. The following is a minimum case for this issue. container = document.createElement('div');
const onClick= jest.fn();
const ref = React.createRef();
ReactDOM.render(
<div onClick={onClick}>
{ReactDOM.createPortal(
<button ref={ref}>click</button>,
document.body
)}
</div>,
container
);
const event = new MouseEvent('click', {
bubbles: true,
});
ref.current.dispatchEvent(event);
expect(onClick).toHaveBeenCalledTimes(1); // 0 |
The funny thing is that this bug actually fixes #11387 And I would consider this the desired behavior 99% of the time. |
I wouldn't say it "fixes" it, it's just an inconsistent behavior. I understand the desire for a different behavior there but let's not spill it off in this thread. (My latest reply is #16721 (comment).) |
* Failing test for #19608 * Attach Listeners Eagerly to Roots and Portal Containers * Forbid createEventHandle with custom events We can't support this without adding more complexity. It's not clear that this is even desirable, as none of our existing use cases need custom events. This API primarily exists as a deprecation strategy for Flare, so I don't think it is important to expand its support beyond what Flare replacement code currently needs. We can later revisit it with a better understanding of the eager/lazy tradeoff but for now let's remove the inconsistency. * Reduce risk by changing condition only under the flag Co-authored-by: koba04 <koba0004@gmail.com>
@gaearon Thanks! Can we expect a |
Yes, but it will take a bit of time for us to test it internally. It's a pretty significant internal change. |
Fixed in |
Is there a way to know what commits have been added between |
* Failing test for facebook#19608 * Attach Listeners Eagerly to Roots and Portal Containers * Forbid createEventHandle with custom events We can't support this without adding more complexity. It's not clear that this is even desirable, as none of our existing use cases need custom events. This API primarily exists as a deprecation strategy for Flare, so I don't think it is important to expand its support beyond what Flare replacement code currently needs. We can later revisit it with a better understanding of the eager/lazy tradeoff but for now let's remove the inconsistency. * Reduce risk by changing condition only under the flag Co-authored-by: koba04 <koba0004@gmail.com>
React version: 17.0.0-rc.0
Steps To Reproduce
root
andportal
divs, check the logs.portal
div'sonClickCapture
noop handler, check the logs again.Link to code example: https://codesandbox.io/s/determined-montalcini-vjrgc?file=/src/App.js
The current behavior
Clicking on the
portal
div logs"portal click"
only.Adding an
onClickCapture
noop handler on theportal
div "fixes" the root'sonClickCapture
handler.You might have to refresh the page between edits, otherwise the root's
onClickCapture
handler might keep working even after removing the portal'sonClickCapture
handler.The expected behavior
Clicking on the
portal
div should trigger the root'sonClickCapture
handler, whether the portal div has anonClickCapture
handler or not.The text was updated successfully, but these errors were encountered: