Introduce navigable's config instance #80
Conversation
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 #74. |
And yes, this also sounds right. |
SHA: 4686c12 Reason: push, by domfarolino Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
I think this PR makes things better and more explicit, but I believe things are still broken even after this. A few questions/points:
Fencemethods, should it ever be possible forinstanceto be null, as we check for in step 2? I think theinstancethat we check when retrieving theFenceobject 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.fencegetter 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