Change:
This is a weird one. Basically, if you add an event listener to the document in an effect that was triggered by an event. e.g. toggles some state, which triggers an effect, which adds a handler to the document. In the normal case the new event handler will "miss" the triggering event, e.g. the click handler won't respond to the click event that triggered it being (omg). HOWEVER, if you render a portal first, the timing changes slightly and the event handler will see the current event. React version: 17 the "show Message" button to see a message toggle in and out the "Render Portal" button (see a portal rendered into the body) the "show Message" button again and notice nothing happens The reason for the final behavior is the click event both opens and closes the message, (calls set state twice) <!-- Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Issues without reproduction steps or code examples may be immediately closed as not actionable. --Link to code example: That they be consistent
17 only?
17 only! downstream issue
well tbh maybe this was present but not observable since before 17 you couldn't attach an event listener "higher up" so there wasn't any way to get in front of the current event
What sounds like a bug here is that is called synchronously at all. It should normally be deferred — which would avoid this issue. So it sounds like there's an unexpected effect flush. Would be nice to dig into why.
I'm sooo confused. I can't reproduce this anymore. The only thing I did was to update Chrome...
Can you still repro it?
bah sorry i was goofing around trying to find a workaround and didn't realize it was saving instead of forking. It should be back to being reproducible
Ok at least I can still sleep at night
What happens here is that the native event bubbles: On the root container On the body (portal target) This is why we get into dispatchEvent twice. Root container pass schedules an effect, and body pass flushes it. Seems like a bug that we flush the effect in this case.
To follow up on this — it does seem like a bug but we can't commit to prioritizing it at the moment. There will be a bunch of work done to clean up and simplify related parts of the code in the coming months so we'll likely address it then. Have you found any userland workaround, or is this a hard blocker for you?
We've got a workaround that's simple and effective in theory . Need to let folks test it out a bit though. Alternatively I think adding listeners in a would work albeit pretty annoying to manage in an effect. For anyone looking, our current workaround is
What I noticed is that for an everything works fine but an actual user click causes the issue described: Edit: I think I'm try attaching a capture listener as well and then check in the bubble event listener if I also captured the event. That fixes the problem at least for mounts in the bubble phase. That looks promising so far: Edit2: Bisecting releases leads to good: 0.0.0-experimental- bad: 0.0.0-experimental- I used experimental releases since the release channel was released less often in that time. So the bug got introduced in Edit3: I don't think the timing of effects changed between 16 and 17. Looks like the timing of events changed due to the changes to the event delegation system. If you add the native listener to instead of , the code works fine. Edit4: ~When the portal is rendered into react attaches its event delegator onto the If I remove that event handler the message can be displayed again.~ See Edit5: Last bit: What makes this bug hard to track down with tests is that you naturally use but within React does not flush discrete updates. Though this is already documented in I'm generally suprised that passive effects are flushed synchronously at all but this does seem to be intended
It seems to me that the assertions in are not correct. The update that is scheduled in the passive effect is deferred as intended when flushing sync but the effect itself should not run when flushing synchronously. IMO would make more sense here. The test comment acknowledges that this is the opposite order and it seems to me that this issue is a good example why this order is problematic: Any side-effect that touches the DOM directly is out-of-order.
Not sure about the intended behaviour but it seems like having the following solve your issue (at least temporarely): On step 3, it displays the message correctly
You can also fix the issue by wrapping in a , like so:
Is there a fix in progress, for upcoming versions, for this bug? I am facing this issue , which cant be resolved because of this.
Could you explain in the Material-UI issue why this can't be resolved for you? We were under the impression that we worked around this bug for our specific usage. For updates on a fix, is the latest update. From what I gather the team is already experimenting with potential fixes. You can subscribe to this () github issue to get notified about updates. Asking for updates does not speed up delivery of said update.
The team has taken a closer look at this now that the related refactors are landing. We can't fix it in a general case without relying on some heuristic. Making all effects synchronous would be bad. Making all of them asynchronous also doesn't work because sometimes we need to flush earlier. The need to flush earlier relates to handling discrete events (like click) that need to be able to observe the already flushed state. A reasonable compromise is to make them synchronous at the end of discrete events (such as click), but asynchronous in other cases. This mirrors the recent changes we've made to state updates in Concurrent Mode to make it easier to adopt. So we this heuristic in Concurrent Mode: I checked that this issue in Concurrent Mode with the latest master commit and now consistently does not show the message (because clicks lead to synchronous effects). We've considered backporting this behavior to React 17. But at this point it's very risky because it's such a subtle change. It's also risky because it would be the first time that we rely on -based heuristics outside of Concurrent Mode. So it's kind of a new territory. Given that it's easy to work around, it doesn't seem like this risk is warranted in React 17. So we've concluded that, while unfortunate, it is safer to not try to fix it in React 17. But Concurrent Mode will have a more predictable behavior here. (Note that it's also quite likely that React 16 also had cases with over-flushing, but triggered under different conditions.) I know this isn't the resolution that most people were hoping for.
Bug; Still clickAwayListener tests fails using React testing library. It seems because of react18.

Discussion:
// TODO: These flags are hard-coded to the default values used in open source. // Update the tests so that they pass in either mode, then set these // to __VARIANT__. <ins> export const enableTrustedTypesIntegration = false; </ins> export const disableSchedulerTimeoutBasedOnReactExpirationTime = false; export const disableNativeComponentFrames = false; // You probably *don't* want to add more hardcoded ones.

export const { disableInputAttributeSyncing, <ins> enableTrustedTypesIntegration, </ins> disableSchedulerTimeoutBasedOnReactExpirationTime, warnAboutSpreadingKeyToJSX, replayFailedUnitOfWorkWithInvokeGuardedCallback,

export const enableUseEffectEventHook = true; export const enableHostSingletons = true; export const enableClientRenderFallbackOnTextMismatch = false; <del> export const enableTrustedTypesIntegration = false; </del> // Logs additional User Timing API marks for use with an experimental profiling tool. export const enableSchedulingProfiler: boolean =