| 14:22 | <Domenic> | shu: callback-context capturing? |
| 14:22 | <Domenic> | maybe just context-capturing |
| 15:18 | <shu> | Domenic: while that does describe what is happening, i'd like a term to help spec authors remember when they should be capturing the context |
| 15:19 | <Domenic> | "time at which it is passed to an API" seems reasonable then |
| 15:21 | <Domenic> | annevk: I'm confused by https://github.com/camillelamy/explainers/issues/4#issuecomment-654127120 . If you do `openedWindow.foo`, the current global object when `foo` is being accessed is `openedWindow`, right? So that'd be wrong for COOP reporting purposes. |
| 15:22 | <annevk> | Domenic: isn't that the relevant global object? |
| 15:23 | <Domenic> | annevk: it's both? |
| 15:23 | <Domenic> | Relevant and current are only different when you're doing something weird like fooGetterFromRealm1.call(realm2Window) |
| 15:23 | <annevk> | Domenic: so why does the security check work then? |
| 15:24 | <Domenic> | annevk: the security check protects against weird things like fooGetterFromRealm1.call(realm2Window) |
| 15:25 | <Domenic> | Hmm no but it's supposed to protect against openedWindow.contentDocument and friends... |
| 15:26 | <annevk> | I thought the current Realm was the Realm that's currently executing code |
| 15:26 | <Domenic> | It's the realm that's code is currently being executed. So in x.y it's the realm of the y function |
| 15:27 | <Domenic> | Maybe this only works because of WindowProxy proxies? |
| 15:28 | <annevk> | Well, not all browsers have those but it does seem something is amiss then |
| 15:29 | <Domenic> | It's hard to believe we missed something this fundamental for so long, so probably I'm still missing something... I'll try to dig through the old commits. We might need to summon bholley. |
| 15:32 | <Domenic> | annevk: maybe https://github.com/whatwg/html/issues/2360 can be closed these days? |
| 15:33 | <shu> | Domenic: fair enough |
| 15:36 | <Domenic> | annevk: ahah. The current settings object is correct because *we're not executing a getter yet* when IsPlatformObjectSameOrigin runs. |
| 15:37 | <Domenic> | E.g. in `w.contentDocument` we've not gotten to the `contentDocument` code yet; we're still in the caller context. |
| 15:38 | <annevk> | Domenic: ah, that will also be true here I think |
| 15:39 | <Domenic> | Indeed, I think so, since it's intercepting in [[Get]] |
| 15:39 | <annevk> | thank deity |
| 16:02 | <annevk> | Domenic: https://github.com/whatwg/html/pull/5560 |
| 16:02 | <annevk> | I think that's the only thing that hasn't landed yet |
| 16:03 | <annevk> | I want to get rid of the Privacy/Security section too, but I think I'll wait until partitioning is further along as that'll make that easier |
| 17:37 | <Domenic> | annevk: any thoughts on https://github.com/whatwg/html/issues/5727 before I jump into it? |
| 18:01 | <annevk> | Domenic: no, but I'd love to see it |
| 18:01 | <Domenic> | Excellent |
| 21:28 | <Domenic> | I am unreasonably excited about https://github.com/whatwg/html/pull/5728 |
| 23:14 | <jugglinmike> | Navigation question here |
| 23:14 | <jugglinmike> | http://web-platform.test:8000/redirect-to-data.py |
| 23:15 | <jugglinmike> | hm, no |
| 23:15 | <jugglinmike> | https://html.spec.whatwg.org/#process-a-navigate-fetch |
| 23:15 | <jugglinmike> | That has, "12. Otherwise, if response has a location URL that is a URL whose scheme is a fetch scheme, then run process a navigate fetch with a new request whose url is response's location URL [...]" |
| 23:16 | <jugglinmike> | by surrounding context, it appears to be intended for "about:" and "data:" URLs, but neither work in Firefox or Chrome |
| 23:17 | <jugglinmike> | I'm trying to learn why they don't work, and what that step actually enables |
| 23:42 | <Domenic> | jugglinmike: I'm pretty sure fetching data: URLs works? And maybe about:blank too? |
| 23:42 | <Domenic> | Oh this is navigating. Then yeah, they definitely work. |
| 23:43 | <Domenic> | So I don't understand what you mean by saying that navigating to data: and about: URLs doesn't work in Firefox and Chrome. |
| 23:44 | <jugglinmike> | That step is specifically about the interpretation of location URLs, so I think it's really about *redirecting* to those schemes |
| 23:44 | <jugglinmike> | It's starting to look like a security measure. The redirect *does* occur in Firefox from an iframe |
| 23:45 | <Domenic> | Interesting |
| 23:45 | <Domenic> | Wouldn't that step also be reached for http and https URLs? |
| 23:46 | <jugglinmike> | Not by my reading; step 9 loops for as long as the scheme is an HTTP(S) scheme |
| 23:47 | <jugglinmike> | the loop breaks when it finds another scheme, and step 11 handles "blob" and "file" |
| 23:47 | <Domenic> | Doesn't it say "location URL is ***not*** a URL whose scheme is an HTTP(S) scheme, then break." |
| 23:47 | <Domenic> | i.e. if it is an HTTP(S) scheme, then it will break |
| 23:48 | <Domenic> | wait |
| 23:48 | <Domenic> | I am just confused |
| 23:48 | <Domenic> | Nevermind that |
| 23:48 | <Domenic> | I guess you are right this is just about: and data: URLs. Probably mostly within iframes. |
| 23:49 | <Domenic> | I should probably sign off for the week, the above was pretty bad :) |
| 23:50 | <jugglinmike> | hah, well, there are certainly better things to be doing on a Friday night |