useEffect fails to fire when hosted in display:none iFrame

[Kikketer]

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

Bug starting at React version 16.9.0

What is the current behavior?

React version 16.8.6: If a react app was hosted in an iFrame and that iFrame was in a display:none style, the useEffect hook would trigger.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:

React version 16.9.0: If a react app using this version is hosted in an iFrame and that iFrame is set to display:none the useEffect hook is never fired.

A CRA app with a very simple useEffect hook is created and hosted here: https://github.com/Kikketer/use-effect-none

The static hosted page is here: https://kikketer.github.io/use-effect-none/

The codesandbox that has this iFrame with display:none can be found here: https://codesandbox.io/embed/react-innerframe-tezku

What is the expected behavior?

The useEffect hook should be fired even if the app is hosted in a display:none iFrame.

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

Firefox, Chrome, Edge (77x on mac) with React 16.9.0 both fail to run useEffect on this iFrame
Safari with React 16.9.0: Does run the useEffect on this iFrame
IE (windows or 11): unknown

[gaearon]

Can you check whether this happens on master?

[Kikketer]

I have rebuilt the react app (that ends up in the iFrame) using the react@canary release:
https://github.com/Kikketer/use-effect-none/blob/master/package.json#L10

I confirmed that the /docs did change, so it appears something is adjusted in the built version.

Unfortunately I'm still not seeing the console.log fire for the useEffect.

[aaronjensen]

I have a likely related issue, but it is Firefox only. Given this repro here:

https://codesandbox.io/s/react-from-parent-frame-useeffect-bug-jpp72

useEffect only fires in Chrome, but not in firefox. The gist is that we're pulling React from another frame, which is hidden. We're doing this to save parse/eval time of React on frames that come and go from an iframe based application plugin. I don't know if this is an officially supported use of React (sharing React and ReactDOM across frames) but it appears to work just fine aside from this case.

[varenya]

@Kikketer I am also seeing a similar issue - are you seeing this only in production build?

[Kikketer]

@varenya The latest test above is using the canary release but that's now 20 days old. I'll update what's out there again and try it (today hopefully).

Confirmed, with the latest canary release it still does not fire. https://github.com/Kikketer/use-effect-none/blob/master/package.json#L10
Canary release: 0.0.0-8d5403877

[varenya]

and looks like it works if the app in the iframe is loaded from the same domain and not if served from a different domain.

[aaronjensen]

@varenya just curious, can you see if it fires on the same domain with firefox?

[threepointone]

This is probably related to #16629 and #16585

[varenya]

Yeah, they all look similar :

In my case while debugging I tried a few things to see how React behaved:

1. Tried visibility: hidden and saw the same issue.
2. Tried display: none and saw the same issue.
3. Works fine with opacity: 0
4. When loading the app from local setup it worked fine, I am not sure how this plays into the issue since we started facing this when we deployed it to our cloud and included the app in a cross-domain environment. And also this is the only bit which differs from the rest of the issues you have mentioned where React is being loaded in the background in different forms and contexts.

Let me know if I can try out something to narrow down the issue further.

Hopefully, this helps in debugging 😄

[threepointone]

Sorry I didn’t clarify; I think we’ve identified the issue and a fix is incoming too.

[varenya]

@threepointone nice

[aaronjensen]

@threepointone that's great. Do you think it will address #16389 (comment) as well? Also, is using React in this way supported?

[pscanf]

Ran into this issue with v16.9.0, seems to be fixed in v16.10.2 (tested in Firefox and Chrome).

[aaronjensen]

My issue with #16389 (comment) appears to be fixed. It looks like it's fixed even on 16.9.0, so it could have been a Firefox bug.

[Kikketer]

Sorry for the long delay but yes I can verify it's working now with 16.12.0 (it was probably fixed way earlier than this). Closing.