| 05:18 | <annevk> | Andreu Botella (he/they): yeah, otherwise it would have used ASCII whitespace (I think it might have done so initially, even) |
| 05:21 | <annevk> | timothygu: that's a nice find, also :-( |
| 05:24 | <hsivonen> | Feeling conflicted about tests like https://github.com/web-platform-tests/wpt/blob/master/html/semantics/scripting-1/the-script-element/script-charset-02.html passing review. On one hand, it caught a bug (not yet sure what) in my code. On the other hand, it tests something more than it's meant to. (Note the location of the meta after a div.) |
| 06:35 | <annevk> | hsivonen: that's likely to happen I think if there isn't a lot of good coverage to begin with, but I also suspect that the <div> coming before was overlooked or considered inconsequential |
| 06:37 | <hsivonen> | Earlier, I found a bug in my code due to WPT author metadata having non-ASCII even though the test lacked <meta charset=utf-8>, so I guess that was good actually. |
| 06:47 | <annevk> | therealandrecasal: commits prefixed with Meta:, Editorial:, or Review Draft Publication: don't make it to Twitter |
| 07:07 | <Noam Rosenthal> | Hi annevk , seems like I'm back in the business of HTML/Fetch/resource-timing integration :) have a couple of PRs for when you have the time (https://github.com/whatwg/fetch/pull/1311 and https://github.com/whatwg/fetch/pull/1309) |
| 08:33 | <ali ikram> | I am new here. Don't know much about this. https://sixtimesanhour.com/ |
| 08:43 | <annevk> | Noam Rosenthal: that's great, I have a bit of a backlog today; not sure if there's anyone else that can help with reviewing but that would be nice |
| 08:56 | <Noam Rosenthal> | annevk: no problem, it's there and ready for when your backlog permits. |
| 09:52 | <annevk> | Jake Archibald: are you taking document.domain into account when determining the origin for history entries? I guess if the origin is the result of URL + sandbox it won't matter, but if the origin is taken from the document/global somehow we have to be careful. |
| 09:53 | <annevk> | Jake Archibald: it came to mind when reading the history.state issue |
| 09:55 | <Jake Archibald> | annevk: yeah, I haven't fully understood document.domain yet. Eg, does it change storage buckets? What happens to an existing IDB connection? |
| 09:59 | <annevk> | Jake Archibald: storage doesn't work for opaque origins and we essentially use the unmodified tuple origin and you'd do a same origin comparison with that (rather than same origin-domain) |
| 10:09 | <Jake Archibald> | annevk: I'm not 100% what to do with the origin of history entries yet, but my gut feeling is:
|
| 10:11 | <annevk> | Jake Archibald: perhaps we can store an opaque flag on the history entry that would avoid revealing it in those cases? |
| 10:12 | <annevk> | Jake Archibald: the 'born' case also seems reason to clear state to me |
| 10:15 | <Jake Archibald> | annevk: The 'born in different domain' case can only happen due to errors and sandboxing right? With sandboxing we don't grant access to storage anyway, and in the error case clearing state seems bad, since a refresh might recover from the error |
| 10:21 | <annevk> | Yeah, maybe. I guess in the specific scenario of short-lived history that is the most likely. Also when coupled with the same origin limitation as if the domain was retired none of the other pages would work either. |
| 12:00 | <Jake Archibald> | annevk: If a script is no-cors, and it triggers an unhandled exception, we normalise the error and remove the stack. But, if a another script catches the error via try/catch, you get the full error & stack. Is that right? Why is the latter ok? |
| 12:03 | <annevk> | Jake Archibald: see https://github.com/whatwg/html/issues/2440 and https://github.com/whatwg/html/issues/958 |
| 12:03 | <Jake Archibald> | ta |
| 17:10 | <Jake Archibald> | annevk should I get a spec PR together for https://github.com/whatwg/fetch/issues/1310#issuecomment-927889382, or does it need more discussion? |
| 17:20 | <annevk> | Jake Archibald: did Chrome's networking and security team have a look? It's probably okay though, within those limits |
| 17:21 | <annevk> | What I'd prefer btw is standardize a TLS handshake that removes the need for the preflight |
| 17:21 | <Jake Archibald> | annevk I'll loop them in. The TLS sounds interesting |
| 17:24 | <annevk> | Jake Archibald: basically something like My-Server-Is-CORS-Aware: [insert origin here] in TLS speak |
| 17:25 | <annevk> | The badness is that someone could declare this as a policy and the server not actually being aware as these things are somewhat far apart from each other, but hopefully it being somewhat difficult helps with that |
| 22:56 | <TabAtkins> | sideshowbarker: You probably want to block this dude https://github.com/mdn/content/issues/9306; he's a crank who's escaped the JS Pipeline Operator repo and started spamming a bunch of other places. |
| 23:14 | <Dominic Farolino> | Are the environment discarding steps ever actually overridden? |
| 23:15 | <Dominic Farolino> | When it doubt, check the service worker spec. Yep, they are defined there |
| 23:38 | <Dominic Farolino> | Does anyone understand this SW algorithm: https://w3c.github.io/ServiceWorker/v1/#service-worker-client-origin ? It acts as if sometimes "service worker client" is not an environment settings object -- is this ever the case? |