Initial navigations to about:blank + fenced frames

[Liam Brady]

Hi navigation folks,

I have some navigation questions regarding initial about:blank navigations and how they relate to fenced frames.

https://g-issues.chromium.org/issues/334991040

I was assigned this bug, where an extension that tries to inject a script into a fenced frame that hasn't done an initial navigation causes the promise to not resolve until the fenced frame is navigated. Iframes don't have this problem. I traced the root cause to the fact that fenced frames do not do an initial navigation to about:blank the same way that iframes do. This results in the fenced frame's document never entering an idle state if not explicitly navigated to a config. There were 2 ways I considered fixing this:

1. Add a carveout in the script injector for un-navigated fenced frames. This is the least amount of work, but feels more like a band-aid solution.
2. Do an explicit navigation to about:blank when a fenced frame is first inserted into a document, the same way that iframes do (HTMLFrameElementBase::DidNotifySubtreeInsertionsToDocument() calls HTMLFrameOwnerElement::LoadOrRedirectSubframe() even if src is blank).
2.5. Do an explicit somewhat synchronous navigation to about:blank to match what iframes do. I say somewhat synchronous because the inner frame root will need to be notified by the HTMLFencedFrameElement through the browser that it needs to perform an about:blank navigation. (Though there's probably some way to have it detect that it's a newly created fenced frame inner root and do the synchronous navigation)

I have a WIP CL for option 1 working (https://chromium-review.googlesource.com/c/chromium/src/+/5492360), but I'd like to get option 2 to work if possible.

When I try to get option #2 or #2.5 to work, a bunch of browser tests start failing (WIP CL for option 2.5: https://chromium-review.googlesource.com/c/chromium/src/+/5512064). It seems that because there's this extra about:blank navigation, a lot of existing tests break because they're waiting for a navigation commit, but the navigation that commits is the about:blank navigation.

Before I actually start trying to fix all these tests (and before I spend any more effort on this bug), I want to confirm that what I'm doing seems reasonable and that there's nothing I'm missing. I guess more specifically these are my questions:

1. Is there any reason to not match the about:blank initial navigation behavior of iframes? Is it fine to have fenced frames do this about:blank initial (possibly semi-synchronous) navigation?
2. How do iframes not run into the browser test navigation observer issue I'm running into? Do their about:blank navigations happen early enough that they commit before any navigation observers even start running?
3. Do you think it's possible to have the same fully synchronous about:blank navigation behavior for inner fenced frame roots? Or is that not doable because of the fact that an inner root lives cross-process from the HTMLFencedFrameElement? Could I have the inner root's frame do an about:blank navigation once it detects it's inserted into the document and knows it's a fenced frame root that has not performed a navigation previously?

Thanks in advance,

- Liam

[Dominic Farolino]

I slightly prefer (2) over (1) personally, since it seems like the cleanest, most sane solution. I'm curious why a bunch of equivalent tests for iframes waiting on navigations aren't failing though. Is it because iframes do their initial about:blank navigation synchronously before any navigation-waiting browser test code is set up to wait for the next navigation? Contrast this with: by the time fenced frames perform their initial about:blank navigation (asyncly with respect to the browser process), the browser test code waiting for subsequent navigations is already set up, and observes the about:blank navigation right when it happens? Is my understanding correct?

One other point I want to make is that (2.5) does not make sense to me. As long as the inner root (which even when about:blank, I believe is hosted in another process for fenced frames) needs to be notified of the need to perform an "initial about:blank navigation" by the outer frame element, this navigation will always be asynchronous from the perspective of the embedder, the browser process, and and any extensions. So if I understand the proposal correctly, calling it any flavor of synchronous seems incorrect. Does that make sense, or am I missing something?

--
You received this message because you are subscribed to the Google Groups "navigation-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to navigation-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/CA%2BA0o62ozyWoxwD%3DUtj4cLwTHtRAHLKu3SQ%3D5YtP3AfeWOV%3Dnw%40mail.gmail.com.

[Arthur Sonzogni]

It would be difficult for me to go into the details of FencedFrame, your patches, and how navigation evolved in the last ~3 years. So I'm not going to risk any recommendations. However, I hope this message might help you understand the context, and make the right decision for FencedFrame.


Iframe behaviors:

The initial empty document: Every iframe starts from the initial empty document. This is created immediately. This is the only document not created by a navigation.

The initial synchronous about:blank navigation: This is an "exotic" navigation specific to Chrome to "about:blank". Blink triggers it if the frame's source is empty or invalid, after initializing the initial empty document. This is the "second" blank document.
This is known as: SynchronouslyCommitAboutBlankForBug778318. This leads to a number of odd situations throughout the navigation stack, and it is spec-incompliant.
We should aim to get rid of it, but this is difficult due to all the dependencies that have aggregated over the years. Some components rely wrongfully on its side effects

Here are some documents we wrote about the subject.

• The initial synchronous about:blank navigation. (@arthursonzogni - January 2021)
• The initial empty document & its problems (@rakina - April 2021)

About fenced frame:

I guess FencedFrame behavior is likely what we would hope for iframe to become at some point (great!) Unfortunately, you are likely facing one of the difficulties preventing us currently. The extension's scriptInjector is likely a component we need to be adapted.

You have to decide in between:

1. You can make this component to stop relying on this bug. This could be what #1 could become. This resolves your issue in the short term, and ideally makes progress toward bug 778318. However, you might face additional issues with other similarly problematic components.
2. You can make the FencedFrame behavior to become closer to iframes (#2 and #2.5). This takes us further "away" from bug 778318. The benefits: you would get a behavior potentially more "consistent" with iframes. Fencedframe aren't tested as thoroughly as iframe, so this would save you from many bugs you would be unlikely to discover proactively.

Arthur @arthursonzogni

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/CAP-uykBP%3DwMJV2SbN9nzQnW%2By69Jwj55MP5DkCRskd%2BrC2T5Rg%40mail.gmail.com.

[Dominic Farolino]

Arthur's comment made me think about this more closely, and I think I now prefer (1) over (2). (Thank you!)

[Liam Brady]

We should aim to get rid of it, but this is difficult due to all the dependencies that have aggregated over the years. Some components rely wrongfully on its side effects

It seems that script injection is one of these components due to the document idle state.

I think that if the end goal of bug 778318 is to not have this extra about:blank navigation, and if tons of components are going to need updating anyway as part of this effort, it probably makes more sense to add the carve-out, which can be expanded on in the future to also accommodate iframes. I'm going to go with option 1 (which is a much smaller change and which I have a working WIP CL for). Thanks for the input everyone!

- Liam