Intent to prototype: Synchronous initial about:blank

[Henri Sivonen]

Summary:

Change our about:blank behavior to match WebKit and Blink for Web compat.

At present, Gecko generates a synthetic (non-parser-created) about:blank document into a browsing context if the document is observed before a parser-generated document appears in the browsing context. However, if the browsing context ends up navigating to about:blank, we currently asynchronously use the remains of the old (Netscape-era) HTML parser to create _another_ about:blank document that replaces the synthetic one and then fires a load event. We use the remains of the old HTML parser, because the newer one would take more event loop spins to fire the load event, which would be an even greater Web compat problem.

This is a long-running Web compat problem, because the second about:blank blows away changes that scripts may have made to the first one. However, Fission changes made things worse and required an added tweak to mitigate the impact, which is why it makes sense to deal with this properly now.

The change is to make the creation of the first about:blank eager, to remove the second parser-created about:blank (and the remains of the Netscape-era HTML parser), and to fire the load event for the synthetic about:blank synchronously if the initial navigation URL of the browsing context turns out to be about:blank.

Bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=543435

Specification:

There's a long-running effort underway to rewrite the relevant spec text:

https://github.com/whatwg/html/pull/6315

Standards Body:

Progress so far reported to WHATWG at https://github.com/whatwg/html/issues/3267#issuecomment-1232545141

How stable is the spec:

As noted, the spec is undergoing a revision. This is targeting observed behavior of WebKit and Blink instead of targeting the currently-committed spec text.

Platform coverage:

All

Preference:

Currently no plan to put this behind a pref.

DevTools bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1789236

Other browsers:

WebKit and Blink already do this and have done this since before Blink forked from WebKit; this change is about changing the Gecko behavior for Web compat.

Web designer / developer use-cases:

The Web developer use case for this is to materialize an iframe and to be able to easily use DOM tree manipulation methods to put content there right away without having to take Gecko-specific asynchronous measures. (This isn't quite advisable, as about:blank is in the quirks mode, but this is the use case.)

web-platform-tests:

There are already numerous tests that intentionally or unintentionally test this area all over various test suites. However, I expect https://github.com/web-platform-tests/wpt/pull/28541 to be intentionally relevant.

Additional information:

While writing new tests before this lands, please avoid the pattern that expects to be able to catch the load event for about:blank by installing the event listener after the iframe has been inserted into the DOM. That is, please don't do this:

<iframe></iframe>

<script>

document.getElementsByTagName("iframe")[0].onload = function() {

  // ...

}

</script>

Please do this instead:

<script>

function someFunction() {

  // ...

}

</script>

<iframe onload="someFunction();"></iframe>

--

Henri Sivonen
hsiv...@mozilla.com

[Henri Sivonen]

On Mon, Sep 5, 2022 at 2:54 PM Henri Sivonen <hsiv...@mozilla.com> wrote:

While writing new tests before this lands, please avoid the pattern that expects to be able to catch the load event for about:blank by installing the event listener after the iframe has been inserted into the DOM. That is, please don't do this:

<iframe></iframe>

<script>

document.getElementsByTagName("iframe")[0].onload = function() {

  // ...

}

</script>

Another pattern that's seen in Gecko-specific tests and that will stop working:

w = window.open("about:blank");

w.onload = function() {

  // Expecting this to run

}

That will no longer work. It's rather surprising that there's a URL for which the onload event isn't listenable, but that's interop. (IE was that way, too.)

--

Henri Sivonen
hsiv...@mozilla.com