jsfiddle.net - The iframe content is not displayed

[xerz-one]

URL: https://jsfiddle.net/gh08oLbq/

Browser / Version: Firefox 79.0
Operating System: Linux
Tested Another Browser: Yes Chrome

Problem type: Site is not usable
Description: Page not loading correctly
Steps to Reproduce:
When loading a custom documentElement into an iframe by replacing the original one, the content is initially displayed but disappears within milliseconds, leaving no items in the DOM tree. This issue is specific to Firefox as it does not happen in Chromium or GNOME Web.

Browser Configuration

• gfx.webrender.all: true
• gfx.webrender.blob-images: true
• gfx.webrender.enabled: false
• image.mem.shared: true
• buildID: 20200720193547
• channel: release
• hasTouchScreen: true
• mixed active content blocked: false
• mixed passive content blocked: false
• tracking content blocked: false

View console log messages

From webcompat.com with ❤️

[cipriansv]

Thanks for the report.

I was indeed able to reproduce the issue.

Tested with:
Browser / Version: Firefox Nightly 81.0a1 (2020-08-19), Chrome 84.0.4147.111
Operating System: macOS 10.15.6

This is the web page displayed in Firefox Nightly:

And this is the web page displayed in Chrome:

Moving the issue to needsdiagnosis.

[denschub]

Thanks much for the report, @xerz-one!

You're right, this is indeed a weird issue. I looked into this and was quite confused as I've never seen that before, but as it turns out, this is a known edge-case with iFrame load timings.

Your code is correctly assigning the value, but unfortunately, shortly after that, the "iframe finishes loading" and thus the original content gets repainted. This appears to be a very niche edgecase, as we've not seen any actual site breakage caused by this so far, but I'll make sure to properly tag the original report.

Luckily, there is a simple workaround for that, though. You can listen to the iFrame's onload event and assign the content in that handler. So, in your example,

-iframe.contentWindow.document.documentElement.replaceWith(
-  doc.documentElement
-);
+iframe.addEventListener('load', (ev) => {
+  ev.target.contentWindow.document.documentElement.replaceWith(
+    doc.documentElement
+  );
+});

would make this work as expected. Hope this helps.

I'll close this bug as a duplicate of bug 728151.

[xerz-one]

@denschub Thanks for the quick response! Sadly, it seems that workaround does the inverse effect and fixes the issue in Firefox while breaking the page in Chromium and GNOME Web. Is this a compatibility bug with those browsers? Regardless, is there any workaround that meets full compatibility?

[denschub]

On a first glance, the spec looks like it says that the load event should be fired, even if there is no src. I'll validate that, and see what's going on here.

[denschub]

Ah, actually, no. Both browsers do fire the load event, but Chrome does it synchronously directly after the appendChild call, while Firefox does it asynchronously sometime after. There is a spec-issue on file, whatwg/html#4965, but there is no real agreement there.

In any case, for you, this should not matter: just make sure to appendChild after you registered the load handler. This works in all browsers: https://jsfiddle.net/t7bn4vf6/