Elaborate on FencedFrameConfig #67
Conversation
|
Per our earlier discussion, all that's left here is making all of the optional stuff into the correct "Null or [...]" language, and specifying the visibility type etc right? |
Yes, I believe so. |
|
@domfarolino Elaborated on the fenced frame config mapping in the tentative way we discussed. (It's broken up into a pending mapping and a finalized mapping. Lookup waits until the config is no longer present in the pending mapping; we can change the description to use an explicit callback as needed later.) |
spec.bs
Outdated
| 1. If *instance*'s [=fenced frame config instance/mapped url=] is null, then the behavior is | ||
| unspecified. | ||
|
|
||
| 1. If this [=document=]'s [=origin=] and *instance*'s |
There was a problem hiding this comment.
Here and elsewhere let's follow the pattern like https://wicg.github.io/turtledove/#:~:text=durationSeconds)%20method%20steps%20are%3A-,If%20this%27s%20relevant%20global%20object%27s%20associated%20Document,-is%20not%20allowed%20to%20use when it comes to accessing the current document.
There was a problem hiding this comment.
Changed to the [=relevant settings object=] to match FLEDGE spec, but lmk if I'm misunderstanding what that means.
* Use infra.spec.whatwg.org * Separate the dfn of fenced frame config mapping from traversable navigable member of the same type * Make algorithm names more casual, and signatures more formal with variables
| containing an <dfn export for="exfiltration budget metadata reference">origin</dfn>, which is an | ||
| [=origin=]; and an <dfn export for="exfiltration budget metadata reference">amount to debit | ||
| reference</dfn>, which is a mutable reference to a non-negative valid floating point number. | ||
| <span class=XXX>TODO: are mutable references a thing in spec?</span> |
There was a problem hiding this comment.
Can this just be the number itself? Specs have the concept of a "pointer to foo" basically, but if we could make this just a plain ole number (instead of a pointer to a number elsewhere) that would be easiest. Is there a strong reason not to do this?
There was a problem hiding this comment.
It has to be a reference because when you perform a fence-escaping navigation, it subtracts this number from the budget and then sets it to 0 (through the reference, so that it applies to all instances created from the same config).
There was a problem hiding this comment.
Where does "the budget" that we subtract from ultimately live? Right now in our spec it seems like a closed loop where the config member is referenced by the instance, and the instance member is referenced by the instantiation algorithm.
There was a problem hiding this comment.
The actual remaining budget lives somewhere defined by sharedStorage spec (on disk somewhere). The amount to deduct lives in the [=fenced frame config=] in the config mapping though.
Not sure how pointers really work in spec, since the copy semantics are not very explicit.
| navigable=]'s [=navigable/traversable navigable=]'s [=fenced frame config instance=]. | ||
|
|
||
| <span class=XXX>This and the below references should point to an actual member on [=traversable | ||
| navigable=], not just the type.</span> |
There was a problem hiding this comment.
I put this as a TODO here that we should follow-up on quickly, but feel free to address this before we land if you want. Basically I think inside this section we should introduce a new member called "fenced frame config instance" or whatever is similar to what we have on DocumentLoader where this can live. That way here and elsewhere we have a concrete thing to initialize, assign, and address wherever we need.
There was a problem hiding this comment.
Agree. Where should it live? If we didn't have to deal with urn iframes I think it could just be attached to the fenced content navigable or whatever, but we probably have to attach it to the root.
There was a problem hiding this comment.
That reminds me: this part about fenced frame config mappings is probably wrong for urn iframes (though it is wrong in the same way that our implementation is "wrong"):
Each [=traversable navigable=] has a <dfn for="traversable navigable" export>fenced frame config
mapping</dfn>, which is a new [=fenced frame config mapping=].
There was a problem hiding this comment.
So the fenced navigable is indeed a traversable navigable, per https://wicg.github.io/fenced-frame/#fenced-navigable-container-fenced-navigable. That's the root, essentially content::Page / content::FencedFrame so the member should probably live there, and iframes can climb the tree to reference it. That's basically what the implementation does, right?
There was a problem hiding this comment.
The config mapping does go in the Page in the implementation, but that is semi-broken for urn iframes because it means that you can load configs that shouldn't really be in scope (e.g., you can in principle take a single urn and then create arbitrarily deep nested urn iframes using that urn).
The config instance goes in the root FTN in the implementation because it's more important for that degeneracy not to exist there. But when urn iframes are gone, it would go in the FrameTree. (Maybe the config mapping should also go there.)
There was a problem hiding this comment.
Ah yeah... hmm OK I think for now we should make it a normal member of "navigable" (basically FTN) with some strong Note saying that once URN iframes are gone this will exclusively live on "traversable navigable".
|
@domfarolino Looks fine to merge to me. Still a little stuff to do in followups. |
SHA: 256b2bf Reason: push, by domfarolino Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Preview | Diff