Spec "disable embedder-initiated nested fenced frame navigations after disabling untrusted network" #148
Conversation
|
Waiting for #146 to be merged for the refs in this to compile. |
|
@domfarolino Addressed comments but still waiting for other PR to unblock |
|
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. |
|
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. |
There was a problem hiding this comment.
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.
|
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? |
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. |
|
Sure, but starting that process with an actual RFC would be probably more useful to get the ball rolling on it. |
Preview | Diff