Repository navigation
Bug: <iframe /> onLoad is not getting triggered after the reload triggered by moving the DOM Node #18752
Description
When an <iframe /> DOM Node is moved to a different place in the tree, Chrome triggers a reload. That reload does not notify event handlers registered via onLoad=. In other words:
- If there is an event handler registered via
onLoad={myCallback}, it will not be fired. - If there is an event handler registered via
iframe.addEventListener("load", myCallback, false), it will be fired.
React version: 16.13.1
Steps To Reproduce
Open a code example below and move the iframe down using arrow button next to it.
https://codesandbox.io/s/serverless-surf-k1ypg?file=/src/App.js
The current behavior
The iframe does not say "Initialized" anymore.
The expected behavior
The iframe should say "Initialized".
Other notes
If you move setIframeContent(e.currentTarget); to nativeLoad and repeat the steps above, it works as expected. The bug does not occur in Firefox.
Activity
[-]Bug: <iframe /> onLoad is not getting triggered after moving the DOM Node in Chrome[/-][+]Bug: <iframe /> onLoad is not getting triggered after the reload triggered by moving the DOM Node[/+]adamziel commentedon Apr 27, 2020
Potentially related? https://github.com/facebook/react/blob/4e3545fd6fc62842d7dbf772923214474f59871a/packages/react-dom/src/events/ReactDOMEventListener.js#L318-L324
eps1lon commentedon Apr 27, 2020
Can only reproduce this in the actual codesandbox browser preview in firefox 75. It's working fine on the standalone page (https://k1ypg.csb.app/) or in chrome 81 regardless of the view.
adamziel commentedon Apr 27, 2020
The firefox part is interesting - I wasn't able to reproduce it there. I just tried on the standalone page and managed to reproduce it with Chrome though:
It only happens with the down arrow since it makes React move the actual DOM Node. Up arrow will move the previous node.
Also see the following Gutenberg issue that many people were able to reproduce and the underlying fix:
eps1lon commentedon Apr 27, 2020
Looks like macOS?
Here are my results on Ubuntu 18.04:
Chrome Version 81.0.4044.122 (Official Build) (64-bit):
Firefox 75.0 (64-bit):
I had some troubles with iframes recently myself but none of these had to do with nested iframes (which applies to the preview window of codesandbox). Generally I
loadevent ordocument.readyState === "complete"(which you need to handle in a passive effect if you're hydrating)I found that calling document.write before the
loadevent would be dropped in firefox.adamziel commentedon Apr 27, 2020
Yes it is!
Nice! So interesting how we're seeing all these OS/Browser inconsistencies here - I did not expect that. I wonder if these iframes are being reloaded in somehow different way/order on different OSes? Also, let me just link to iframe reload issues in case there is something relevant in comments:
Portals sounds like a good idea for an even better Gutenberg fix. I just played with them and I have some additional findings:
Setting
<iframe srcDoc="<!DOCTYPE html>"fixes the issue for me:https://codesandbox.io/s/dazzling-tdd-50r9o?file=/src/App.js
useRefonly works consistently whensrcDocis setOtherwise
ref.currentstays null. If you setrefto a custom callback, it's getting called with a correct DOM node: https://codesandbox.io/s/young-water-km9v5?file=/src/App.jsThis seems like some kind of race condition though as I'm getting inconsistent results:
TIL, thank you!
nearestnabors commentedon Jul 21, 2020
MacOS here—was unable to reproduce with Chrome or Firefox using most recent React nor with 16.12.
liqwid commentedon May 20, 2022
Found how to reproduce the bug easily and consistently:
MacOs 11.6 20G165Chrome Version 101.0.4951.64 (Official Build) (x86_64)react, react-dom 17.0.2To reproduce turn off all browser extensions, and use the codesandbox in examples - it starts to reproduce consistently.
spector32 commentedon Dec 9, 2022
This also happens for me on Brave:
[Version 1.45.131 Chromium: 107.0.5304.110 (Official Build) (64-bit)]