00:30 | <Domenic> | arai: I think Chromium has some kind of annotation on all side-effecting getters in Web IDL, specifically for DevTools purposes. I'd suggest poking around the codebase. |
00:36 | <arai> | great :) I'll look into it |
05:27 | <arai> | found [Affects=Everything] extended attribute for attributes: https://chromium.googlesource.com/chromium/src/+/master/third_party/blink/renderer/bindings/IDLExtendedAttributes.md#affects_m_a , but I don't see the occurrence in the source https://source.chromium.org/search?q=Affects%3DEverything&ss=chromium%2Fchromium%2Fsrc:third_party%2Fblink%2Frenderer%2Fcore%2Fdom%2F |
05:27 | <arai> | so I guess there's no such attribute right now? |
08:30 | <Noam Rosenthal> | Domenic Jake Archibald : I'm trying to understand some of the navigation-API changes and how they relate to navigation timing. In https://html.spec.whatwg.org/#create-navigation-params-by-fetching #8, we set the initiator type of the request to the container's name, if the container is not null. Setting the initiator type makes Fetch automatically report resource timing. |
08:38 | <Noam Rosenthal> | yea I think it's a bug, will post a PR |
08:38 | <Domenic> | (This seems unrelated to the navigation API, I guess you meant the rewrite.) |
08:44 | <Noam Rosenthal> | Domenic: yes, I meant the rewrite. |
08:51 | <Noam Rosenthal> |
|
12:54 | <annevk> | Mattias Buelens: hey, if you have a quick minute to look at https://github.com/whatwg/fetch/pull/1569 and comment on the state of Streams and event loop integration I'd appreciate it (I realize I might have asked about this before, I'm afraid I forgot) |
13:15 | <Noam Rosenthal> | annevk: how about inlining "package data" in "consume body"? it's the only caller AFAICT and it's not exported |
13:16 | <Noam Rosenthal> | instead of passing promises around we could use a single promise in the scope and resolve/reject it |
13:18 | <annevk> | Noam Rosenthal: hmm maybe, I don't immediately see it as we invoke it twice, but it might be possible |
13:18 | annevk | looks at blame |
13:21 | <annevk> | Not quite unlike how it started out: https://github.com/whatwg/fetch/commit/313cc37deb6346690a5f6a7dd096cb74afa19d03 |
13:21 | <Noam Rosenthal> | annevk: we invoke it once in consume body |
13:21 | <Noam Rosenthal> | (before my patch) |
13:22 | <Noam Rosenthal> | Not quite unlike how it started out: https://github.com/whatwg/fetch/commit/313cc37deb6346690a5f6a7dd096cb74afa19d03 |
13:23 | <annevk> | Noam Rosenthal: well, but before is buggy in a different way in that it awaits a promise it resolved with a non-JS value |
13:24 | <Noam Rosenthal> | right. let me play with inlining and it would hopefully end up in a better state |
13:45 | <annevk> | Some people, when confronted with a problem, think “I know, I’ll use HTTP-augmented ABNF.” Now they have 1# problems. |
15:19 | <Noam Rosenthal> | annevk: New version up (building), I'm much happier with this. Takes event-loops into account by running "package" in parallel and queuing resolve/reject on this 's event loop. It's much closer to implementations than what we had there before |
16:35 | <annevk> | Noam Rosenthal: package cannot run in parallel though as it creates JS objects |
16:39 | <Noam Rosenthal> | annevk: hmm right. just thought that I'd revise it though to have the different functions (.json() etc) pass a packager callback rather than have this switch statement |
16:40 | <Noam Rosenthal> | ... since it creates JS objects it needs to run on the main thread, after the task queuing I guess |
16:43 | <annevk> | Noam Rosenthal: for the case where body is null we also cannot queue a task I think as that will be observable, at least in theory that promise resolves in the task that gets hold of it |
16:44 | <annevk> | I will be able to review tomorrow, but after that it might have to wait until 2023; back Jan 2 or so |
16:45 | <Noam Rosenthal> | I will be able to review tomorrow, but after that it might have to wait until 2023; back Jan 2 or so |
16:45 | <annevk> | thanks, happy holidays |
22:43 | <ser.bicer@hotmail.com> | https://github.com/census-instrumentation/opencensus-go/blob/v0.24.0/go.mod#L1 |