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.
Would this mean that any iframe navigation would report resource timing? That would be a bug, as we need to report only the ones initiated from the parent (the source snapshot's fetch client I guess? https://html.spec.whatwg.org/#source-snapshot-params-client)

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>

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.
Would this mean that any iframe navigation would report resource timing? That would be a bug, as we need to report only the ones initiated from the parent (the source snapshot's fetch client I guess? https://html.spec.whatwg.org/#source-snapshot-params-client)

https://github.com/whatwg/html/pull/8638
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
hehe that's how it goes sometimes
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
thanks for the heads up, enjoy the holiday
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