| 19:11 | <Mek> | does it make sense to talk about the relevant realm/relevant settings object from the definition prose of a static operation? It seems like that is something that should be well-defined, but not entirely sure how to best write it, since there is no platform object or |this| value... |
| 19:46 | <Domenic> | Mek: generally you should use "current settings object" in that situation. It will be identical to "the realm of the static function being called" |
| 19:47 | <Domenic> | (which could be different from "the realm of the constructor, which is the thisArg", in cases like `otherWindow.CSS.escape.call(window.CSS)`) |
| 19:56 | <Domenic> | annevk: do you think "site" should be "scheme-and-registrable domain" or should it be "scheme-and-registrable-domain or origin"? |
| 19:57 | <Domenic> | Going to try the former for now |
| 20:01 | <Mek> | ah, okay. So even if you call my_iframe.contentWindow.SomeInterface.staticOperation() current settings object would still be the iframes settings object? |
| 20:02 | <Domenic> | Mek: yep |
| 20:02 | <Mek> | okay, thanks |
| 20:08 | <annevk> | Domenic: or origin, otherwise what’d we call that? |
| 20:08 | <Domenic> | annevk: agent cluster key? Unsure how broadly applicable the agent cluster key concept is... |
| 20:09 | <annevk> | Domenic: I think that is the concept |
| 20:09 | <Domenic> | I guess I am a bit confused... the only use of the "site" concept directly is possibly for agent cluster key, I think. Everything else wants to compare origins for (schemeless) same-siteness |
| 20:10 | <annevk> | Domenic: without or origin same origin is not a subset |
| 20:10 | <Domenic> | Given that I'm not sure I see as much value in defining "site" and "schemless site" |
| 20:10 | <Domenic> | Right, "same site" would need to inspect origin stuff |
| 20:10 | <annevk> | Domenic: gotta go, will elaborate tomorrow |
| 20:11 | <Domenic> | K. Will start by defining "same site" and "schemelessly same site" on origins; I think I understand the requirements there at least. |
| 20:17 | <Mek> | Domenic: do you happen to know if we have a convenient incantation for "first party context" vs "third party context", i.e. if settings object's origin is (not) the same as the top-level origin. It's something we check in a lot of places in chrome, but I haven't been able to find any specs yet that actually include such checks... |
| 20:18 | <Domenic> | Mek: not off the top of my head, sorry... |
| 20:18 | <Mek> | np, thanks anyway |
| 21:46 | <Mek> | `If |environment|'s [=environment settings object/origin=] is not [=same origin=] with |browsing context|'s [=top-level browsing context=]'s [=active document=]'s [=relevant settings object=]'s [=environment settings object/origin=],` does what I want I think, but it seems like there must be a beter way... |
| 21:46 | <Mek> | |
| 22:18 | <Domenic> | Mek: I think you can just go "active document's origin" |
| 22:21 | <Mek> | what definition of "origin" would that be? |
| 22:22 | <Mek> | ah, never mind, I see |
| 22:24 | <Mek> | I didn't realize the generic definition for "origin" was monkey patching the definition of Document... |