Spec: Wait for network revocation in nested fenced frames before disabling network. #176
Conversation
spec.bs
Outdated
|
|
||
| 1. <p class=XXX>TODO: destroy the nested traversable.</p> | ||
|
|
||
| 1. [=Recalculate the untrusted network status of all fenced frame descendants=] given the |
There was a problem hiding this comment.
Do we also have to do this during iframe teardown? I don't think so but I want to be sure.
There was a problem hiding this comment.
Only if the iframe teardown results in a child fenced frame also being torn down, but that will get caught by this anyway, so we don't need to add anything for iframes.
There was a problem hiding this comment.
Wait how will it get caught by this? Check out the iframe destruction/removal path — I don't think it results in fenced frames being "removed" from the DOM, so I don't think we'd go through this path for fenced frames if their iframe parent is removed.
Also, note that the recalculate algorithm requires being in parallel, but the removal steps are not called from in parallel. That's a bug.
There was a problem hiding this comment.
I guess I had assumed it was a cascading operation, but it looks like it's not. I'll add a separate removed from a document algorithm for iframes. I didn't see any place where this was being called for iframes to begin with, so it should be okay to add a new algorithm.
I'm not sure if there's some common path that would be better to put this in. I considered the node removal algorithm, but that lives in the DOM spec, and I don't think that's supposed to get access to the concepts of traversables and node navigables. Let me know if there's a better spot you think this could live in.
I also updated the calls to be run in parallel.
There was a problem hiding this comment.
It's already being called here: https://html.spec.whatwg.org/C#the-iframe-element:html-element-removing-steps. It's using the more appropriate removing steps hook, instead of the removed from document hook, which I have a goal of removing from the HTML spec anyways, so I don't think we should add more instances of it sadly.
So I guess we should just monkeypatch the existing iframe algorithm, and as a follow-up, some day we can probably modify our spec to not use the removed from document hook.
There was a problem hiding this comment.
One more issue I spotted is that the https://wicg.github.io/fenced-frame/#revoke-network-for-a-partition-nonce algorithm uses "this" which it cannot do since it is called from an in parallel context. I think we should fix that in this PR.
Modified to take in a |
This PR introduces a new algorithm:
Recalculate the untrusted network status of all frames. This is called whenever a fenced frame marks its network as disabled, and checks to see if any ancestor fenced frames are now allowed to have their network access be fully revoked and gain access to unpartitioned data.This PR modifies
disableUntrustedNetwork()to not resolve the promise, and instead puts the promise into the fenced frame config instance to be resolved once the frame tree is considered to have its network fully revoked.This builds off of the work in #146, and this should only be merged after #146 is merged.
See: issue #168
Preview | Diff