Use DOM's post-connection steps for <iframe> elements - #10840
Conversation
|
I'm a bit confused. How does Gecko not have post-connection steps? I mean, conceptually scriptrunners do that. |
|
@smaug---- I’m just going off the WPT results linked above—Firefox fails the insertion test. Gecko may well be capable of implementing post-connection timing via ScriptRunners, but it seems to not use that capability for iframe insertion. |
|
Ah, but that is just about the load event, no? |
|
Well the load event is the only way an earlier-inserted frame can observe that a later-inserted iframe’s content window is null, and has not yet been created yet, because the nested document is created during the post-connection steps, at the same timing as the load event. So it is about the load event, but also about nested document creation. |
|
One could mix script elements and iframes in the test, no? Earlier script accessing iframe. (though I think Gecko would synchronously create a content window when accessed first time.) |
In whatwg/dom#1261, the concept of DOM post-connection steps were introduced, as a checkpoint to run scripts and create browsing contexts synchronously during insertion, but after all DOM mutations are complete. After that, #10188 landed to make use of the post-connection steps for
<script>elements, but no such PR was made for<iframe>elements, despite 2/3 browser engines implementing iframe insertion with post-connection steps, and no strong objections from the third (Gecko). This PR updates the iframe processing model to create its nested navigable/browsing context during the element's post-connection steps, instead of the normal insertion steps. Fixes #10828.@smaug---- Are you on board with this? Is it fair to say there are no strong objections for using this timing for
<iframe>elements, as Chromium and WebKit do?/iframe-embed-object.html ( diff )