Introduce navigable's config instance

[domfarolino]

I think this PR makes things better and more explicit, but I believe things are still broken even after this. A few questions/points:

• 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? 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?

---

Preview | Diff

[gtanzer]

@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.

[domfarolino]

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.

[gtanzer]

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.