Spec "disable embedder-initiated nested fenced frame navigations after disabling untrusted network"

[gtanzer]

---

Preview | Diff

[gtanzer]

Waiting for #146 to be merged for the refs in this to compile.

[gtanzer]

@domfarolino Addressed comments but still waiting for other PR to unblock

[domfarolino]

Just pinging @VergeA to make sure he's aware of this PR since I think he'll be taking it over once #146 lands.

[VergeA]

The changes from #146 have made it into the main branch (by way of other stacked PRs). I'll fix the merge conflicts here and ping again when it's ready for review.

[VergeA]

Alright, this should be up to date now, although this change will be affected by the transition to "untrusted network status" as written in #176.

[domfarolino]

I just want to double check something — you are intending for this PR to have no effect in a primary frame's Document, right? The only place this would have an effect in is inside a fenced frame which is trying to set the config attribute on a nested fenced frame. If that top-level fenced frame has a config instance with disabled network, then we would fail to navigate the nested fenced frame as expected. But if we're running the config setter from a primary main frame's script, the config instance will never be null and therefore this PR won't have an effect in that case. That's the intention, right?

Also, if there are any tests you can link to from the PR, please do so. That would help a lot.

[VergeA]

Yes, your understanding is correct. See the corresponding Chromium CL here which implements that behavior explicitly.

RE linking tests: Our network revocation tests are in Chromium's internal WPT directory right now. The plumbing to allow our RemoteContext-based fenced frame tests to work while disabling network everywhere else requires a window.internals API that is not available to other browsers. Is there a way you recommend linking internal tests that doesn't clash with the existing WPT linking format? Or should they be left out if they aren't upstreamed?

[domfarolino]

Is there a way you recommend linking internal tests that doesn't clash with the existing WPT linking format? Or should they be left out if they aren't upstreamed?

The right way would be to file whatever bugs are necessary against web driver and WPT's test harness infrastructure so that some sort of engine-agnostic API can be implemented to expose the right behavior. I recall being able to file RFCs about this somewhere, maybe you could try and track this down. In the meantime, I would file an issue against our repository describing the task of doing exactly that, and linking to it from our spec where this is implemented, since it's a pretty big issue — it means no other browser that implements fenced frames can assert the correct behavior here.

[VergeA]

@blu25 has already filed an issue against our repository to get a new Webdriver API implemented: #192.

It is already linked in the spec, on line 1993 in the incoming branch.

[domfarolino]

Sure, but starting that process with an actual RFC would be probably more useful to get the ball rolling on it.

[VergeA]

Sure, but starting that process with an actual RFC would be probably more useful to get the ball rolling on it.

To clarify, is starting that process a blocker for this PR? This RFC work came up again in a Chromium code review recently, so I'm circling back here as well. We're planning to have the Webdriver/WPT work done by the end of this year (and will ideally have an RFC filed well before then).

[domfarolino]

No as long as we have an issue filed (and maybe a TODO in this PR linking to that issue) to finally add the tests to the spec once they are upstreamed into external/wpt.

[VergeA]

I created a sub-issue of #192 to link the tests in the spec: #207.

I've also linked to it in the spec in my latest commit.

[VergeA]

Build appears to be broken, will re-request review one I fix it.

[VergeA]

This feature branch was added directly to the repo instead of the fork, and was actually pretty behind. I rebased locally, force-pushed, and used the new untrusted network status concept to re-implement the logic here.

[domfarolino]

So this generally looks good, and it's simple. But I have a question about #148 (review) and your response in #148 (comment). Why is it OK to allow primary-frame-initiated navigations to take place on top-level fenced frame elements whose network is disabled?

Or would those navigations actually fail somewhere further down the pipeline, because their network has been revoked? And if that's the case (i.e., navigations would organically fail somewhere in the loading pipeline because their network was revoked), then why do we need this PR?

[domfarolino]

Suggested change

	1. If |instance| is not null, then if |instance|'s [=fenced frame config instance/untrusted
	1. If |instance| is not null, and it's [=fenced frame config instance/untrusted

(Will likely need rewrapping)