NEW294334
3rd nested iframe with srcdoc does not render in safari 
https://bugs.webkit.org/show_bug.cgi?id=294334
Summary 3rd nested iframe with srcdoc does not render in safari
Brendan Ronan
Reported 2025-06-11 12:27:45 PDT
Open the following HTML in a chromium based browser, and safari: ``` <!DOCTYPE html> <html> <head></head> <body> <script type="text/javascript"> document.addEventListener("DOMContentLoaded", () => { var frame = document.getElementById("iframe") console.log("adding window load listener") frame.contentWindow.addEventListener("load", () => { console.log("window loaded") }) }) </script> <iframe id="iframe" srcdoc="<p> hello world! <p>"></iframe> </body> </html> ``` Note that chromium will output "window loaded" but safari will not
Attachments
Add attachment proposed patch, testcase, etc.
Anne van Kesteren
Comment 1 2025-06-16 23:07:23 PDT
If you add an `onload` attribute it will fire reliably so I suspect that means `srcdoc` is loaded synchronously in WebKit, unless there is something in there that delays the load event (e.g., an image). That does indeed seem like something that needs to be fixed. For now I'd recommend registering the load event listener at the time the `iframe` element is created.
Radar WebKit Bug Importer
Comment 2 2025-06-18 12:28:19 PDT
<rdar://problem/153759669>
Brendan Ronan
Comment 3 2025-06-26 10:10:02 PDT
(In reply to Anne van Kesteren from comment #1) > If you add an `onload` attribute it will fire reliably so I suspect that > means `srcdoc` is loaded synchronously in WebKit, unless there is something > in there that delays the load event (e.g., an image). That does indeed seem > like something that needs to be fixed. For now I'd recommend registering the > load event listener at the time the `iframe` element is created. I have been investigating this more, and I think I have uncovered the deeper issue that is causing the bug we are experiencing. Take this HTML and open it in safari and chromium <!DOCTYPE html> <html> <head> </head> <body> <script type="text/javascript"> window.addEventListener("load", () => { var frame = document.getElementById("iframe1") frame.addEventListener("load", () => { var frame2 = frame.contentWindow.document.getElementById("iframe2") frame2.addEventListener("load", () => { var frame3 = frame.contentWindow.document.getElementById("iframe2").contentWindow.document.getElementById("iframe3") console.log("setting iframe3 srcdoc (will not work on safari)") frame3.srcdoc = "<p> hello world 3! <p>" }) frame2.srcdoc = "<p> hello world 2! <p> <iframe id='iframe3'> </iframe>" }) frame.srcdoc = "<p> hello world! <p> <iframe id='iframe2'> </iframe>" }) </script> <iframe id="iframe1"></iframe> </body> </html> You will see that in safari, "hello world 3!" is not rendered, despite the srcdoc property being set. In chrome, it does render
Ahmad Saleem
Comment 4 2026-01-10 01:24:54 PST
Using comment 3 - I am able to reproduce the issue on WebKit ToT (305404@main) and we still do not get `hello world 3!`. While both Chrome Canary 145 and Firefox Nightly 148 get it.
Ahmad Saleem
Comment 5 2026-01-10 15:03:45 PST
``` bool HTMLFrameOwnerElement::isProhibitedSelfReference(const URL& completeURL) const { if (completeURL.isAboutBlank() || completeURL.isAboutSrcDoc()) return false; // We allow one level of self-reference because some websites depend on that, but we don't allow more than one. bool foundOneSelfReference = false; for (RefPtr<Frame> frame = document().frame(); frame; frame = frame->tree().parent()) { RefPtr localFrame = dynamicDowncast<LocalFrame>(frame); if (!localFrame) continue; // Use creationURL() because url() can be changed via History.replaceState() so it's not reliable. if (equalIgnoringFragmentIdentifier(localFrame->document()->creationURL(), completeURL)) { if (foundOneSelfReference) return true; foundOneSelfReference = true; } } return false; } ``` @Ryosuke - another one for you, this fixes at least test case from Comment 3 but not from Comment 0. I think we can separate Comment 3 as separate test.
Ahmad Saleem
Comment 6 2026-01-11 01:29:01 PST
Updated URL to failing test since we pass `Comment 03` test now. This bug is now about `Comment 0` test.
Note You need to log in before you can comment on or make changes to this bug.