Closed domfarolino closed 1 year ago
@domfarolino
The way I envision the ideal world here, is that because we have to support URN iframes, we make the "instance" retriever in both the window.fence getter and the fence.* methods both traverse upwards until they find a navigable with a non-null instance and both reference that instance. Does that sound right?
Yes, that sounds right. There would be some algorithm "Get the current fenced frame config instance" which is implemented as that for now, and later becomes simpler.
OK, let's implement that in a PR just after this one to fix all of this mess. I'm just trying to land this for https://github.com/WICG/fenced-frame/pull/74.
In the Fence methods, should it ever be possible for instance to be null, as we check for in step 2? I think the instance that we check when retrieving the Fence object in the first place (https://wicg.github.io/fenced-frame/#dom-window-fence > Step 2) should be a sufficient gate, such that we don't have to check for instance anymore inside the methods, right?
And yes, this also sounds right.
I think this PR makes things better and more explicit, but I believe things are still broken even after this. A few questions/points:
Fence
methods, should it ever be possible forinstance
to be null, as we check for in step 2? I think theinstance
that we check when retrieving theFence
object in the first place (https://wicg.github.io/fenced-frame/#dom-window-fence > Step 2) should be a sufficient gate, such that we don't have to check for instance anymore inside the methods, right? The way I envision the ideal world here, is that because we have to support URN iframes, we make the "instance" retriever in both thewindow.fence
getter and thefence.*
methods both traverse upwards until they find a navigable with a non-null instance and both reference that instance. Does that sound right?Preview | Diff