| 00:09 | <bkardell> | annevk: I think this is what we said? https://github.com/whatwg/html/pull/9452/commits does it help? |
| 01:40 | <Domenic> | interesting... does the html build use Prince XML? |
| 01:41 | <Domenic> | https://wicg.github.io/turtledove/ has a couple fields that are passed to the browser in one realm, stored for a while, and then passed to a function in another realm. The spec currently uses JSON for this, where it might be able to use StructuredSerializeForStorage() instead, but my question for this group is whether there's a good WebIDL pattern for documenting that restriction on types and creating the resulting objects in the right realm? |
| 01:42 | <Domenic> | Not sure what you mean by Web IDL pattern. Generally IDL object instances are restricted by realm? |
| 02:07 | <bkardell> | The full version that runs on CI does, to produce the PDF |
| 03:17 | <Jeffrey Yasskin> | Not sure what you mean by Web IDL pattern. Generally IDL object instances are restricted by realm? |
| 03:20 | <Jeffrey Yasskin> | Similarly, a StructuredCloneableObject could do the same with StructuredSerializeForStorage, I think. And we could change postMessage to take those instead of any... |
| 03:21 | <Jeffrey Yasskin> | (Well, not really, because of the transfer argument, but there might be other simpler places.) |
| 03:22 | <Domenic> | I see what you mean, hmm... |
| 03:23 | <Domenic> | Very related to your point in https://github.com/whatwg/webidl/issues/1327. This axis of "realm-independent vs. not" is not one I've thought enough about, I guess, but it's an important one. |
| 03:23 | <Jeffrey Yasskin> | Yeah. I'm thinking about this because Protected Audience does a lot of these cross-realm transfers. |
| 03:24 | <Domenic> | I feel like we've also used dummy realms for related things in the past? Like a realm that is never exposed to anyone. IndexedDB maybe? |
| 03:25 | <Jeffrey Yasskin> | IndexedDB does that, but I don't think it has to. It does, in fact, re-serialize from that dummy Realm into the actual storage. |
| 03:26 | <Jeffrey Yasskin> | I think this has gotten clearer recently, as we've re-cast the WebIDL types into Infra types. |
| 03:27 | <Domenic> | I think the major missing piece is a kind of recursive definition of "realm-agnostic". Like a dictionary containing an interface is not, a dictionary containing strings is. |
| 03:28 | <Jeffrey Yasskin> | I thought we'd need that, but actually, you can pass a reference to an interface through 'in parallel', create a dictionary containing that reference in parallel, and then queue a task to return that dictionary to JavaScript. |
| 03:30 | <Jeffrey Yasskin> | You couldn't create such a dictionary in parallel from whole cloth, and you couldn't pass it all the way to a different agent cluster, but otherwise it works. |
| 03:33 | <Jeffrey Yasskin> | (Maybe we do want a recursive definition of "safe to pass across origins and agent clusters"?) |
| 04:16 | <Domenic> | Hmm, doing that would make me pretty uncomfortable... I guess because it's too easy to treat that reference as something non-opaque. |
| 06:55 | <annevk> | There's a lot of hand-waving around in parallel, agents, and tasks today. It would be nice to see that formalized, but it would be quite a bit of work. I'm not sure why IndexedDB needs a custom realm. It can just store the serialized thing, no? Might be an artifact from how "structured clone" was written back in the day and never properly refactored. |
| 07:07 | <Domenic> | Yeah that sounds likely |
| 07:28 | <annevk> | Domenic: so for https://github.com/whatwg/html/pull/4613 I guess you ended up using rebase & merge and that doesn't cause attribution to go wrong? (Because it will use attribution from the commit which was correct.) |
| 07:37 | <Domenic> | Yep |
| 09:43 | <annevk> | Ah, good to know that works. |