2024-03-05 [08:58:41.0510] I will miss the AsyncContext meeting, but I want to encourage Googlers to get in touch with Jatin on the CWI Wiz team re: testing AsyncContext. If needed, maybe Igalia could provide them a custom Chrome build including AsyncContext for testing. [08:58:57.0759] sorry I would like to talk about the FinalizationRegistry context issue but I won't be able to today [08:59:53.0778] but feel free to discuss without me; I'm fine with reaching the other conclusion, but I'd like us to strongly consider simplifying and reducing overall complexity vs Justin's proposal. [10:17:21.0918] Is the AsyncContext meeting open to interested parties who are not delegates? [10:17:56.0985] A member of our Google JS/TS Libraries team is very interested in the AsyncContext effort because he needs it for our libraries. [10:18:04.0303] Steve Hicks [10:26:10.0633] > <@bradfordcsmith:matrix.org> Is the AsyncContext meeting open to interested parties who are not delegates? I'm not sure if the meeting is open for anyone to join, but I think we've had at least one meeting where we had some non-delegate [10:31:15.0641] I would certainly like Steve to be able to attend if he wishes. I think he likely has some interesting ideas to contribute, and he definitely wants to use the upcoming AsyncContext feature to inform development we need. [11:01:35.0764] Steve can definitely join; he is a Google employee, and Google is an Ecma member [11:01:52.0729] the important thing is that intellectual property contributed by Steve is licensed for the standard, which is already covered [11:02:18.0417] I'd like this call to be open to all relevant experts; please propose any more people who you want to join, and we'll figure out how to get them in. [11:02:30.0448] this might require signing certain legal agreements to license intellectual property [11:03:28.0019] did you end up discussing the FinalizationRegistry snapshot question? [11:06:38.0021] > <@littledan:matrix.org> did you end up discussing the FinalizationRegistry snapshot question? in the end we decided to use construction-time [11:09:31.0063] I think we should be open to anyone. I had invited Steve to join in Jan, but he declined. If he's changed his mind I'd be happy to have him. [11:11:03.0682] Steve has also joined in other TC39 calls, so I'm kinda surprised that Bradford is even asking... [11:14:22.0648] Thanks for confirming that Dan. I invited Steve to the meeting this morning (ineptly, as it turned out, so he missed it this time), but then I thought maybe I was making an incorrect assumption about access to this group. The "tools meeting" has always been more of a community thing, and I suddenly thought I might be incorrectly assuming the same rules for this one. [11:15:26.0111] in general Ecma defers to members to decide who represents them [11:15:44.0809] but also this isn't a main TC meeting so it's just informal; we can decide on whatever attendance rules we want [11:16:35.0562] but if there is a substantial contribution that comes from someone who doesn't have a membership agreement set up for intellectual property, they need to sign the non-member contributor form https://tc39.es/agreements/contributor/ [11:16:40.0938] (this isn't the case for Steve) [11:17:04.0218] in theory, discussion can constitute contribution, so better safe than sorry in requesting signatures, IMO [11:17:27.0480] * (this isn't the case for Steve--he is covered as a Googler) 2024-03-06 [06:42:42.0538] oh, we forgot to discuss the exact semantics of `AsyncContext.Snapshot.wrap` length in yesterday's meeting [06:42:44.0695] see https://github.com/tc39/test262/pull/3874#discussion_r1501253279 [06:43:18.0986] * oh, we forgot to discuss the exact semantics of the wrapped function's length in yesterday's meeting [09:49:04.0513] Happy to reuse Shadow Realms’s AO 2024-03-07 [18:32:24.0142] Are you referring to https://tc39.es/proposal-shadowrealm/#sec-copynameandlength? [19:05:32.0332] Yah 2024-03-13 [07:37:59.0721] https://github.com/nodejs/node/pull/52065 I am prototyping `using` declaration support with `AsyncLocalStorage`. In order to address unexpected declaration without `using`, a leakage check is performed when a task (AsyncResource) callback is finished. If there is any active disposable async local storage value, an error is emitted to hint such misuse. [07:44:03.0932] This could help in less refactoring when adding async context support, i.e. no need to create a new function/arrow function for sub-operations and avoid violating TCP when mutating async context values, as rbuckton suggested. [07:54:29.0882] what happens if you have `AsyncLocalStorageDisposableStore`s created and disposed of in a non-stacked way? [07:57:43.0252] At the moment, it restores the bound `AsyncLocalStorage` value to the one when it was created. However, I think it could avoid restoring the value if the bound `AsyncLocalStorage` was changed so that it could produce fewer conflicts. [12:51:31.0123] Hey, I have the V8 design doc ready, pending any comments you might have. PTAL [12:51:32.0008] https://docs.google.com/document/d/19gkKY6qC3L5X8WtSAmFq33iNnzeer1mL5495oT1owjY/edit?usp=sharing [12:51:41.0031] * Hey, I have a version the V8 design doc ready, pending any comments you might have. PTAL [15:08:41.0037] LGTM, ship it! [15:09:24.0408] hey, given that it seems that proposals don't really need their web integration fully worked out until Stage 3 (I previously thought it was needed at 2.7), is AsyncContext good to go to Stage 2.7 at the next TC39 meeting? I think it is! [15:17:08.0255] it seems like there's been lots of changes since it got stage 2 - i've not been able to follow the very complex PRs/discussions, fwiw - and it'd be good to have a thorough recap/update before asking for advancement (iow, pls don't underestimate the timebox) [15:18:13.0634] yep, +1 on a strong recap and allocating an hour to this [15:23:06.0044] littledan: I had a document that I shared with Scott Haseley with some ideas for the task attribution integration. Do you think it would be good to link it? [15:23:16.0497] it's very rough around the edges and not anything formal [15:23:29.0665] * littledan: I had a document that I shared with Scott Haseley in January with some ideas for the task attribution integration. Do you think it would be good to link it? [15:26:48.0187] > <@abotella:igalia.com> littledan: I had a document that I shared with Scott Haseley in January with some ideas for the task attribution integration. Do you think it would be good to link it? yes, that's great! it'd also be good to link this to some kind of acknowledgement that the web platform snapshot propagation semantics are not yet well-defined, and this will be a blocker for shipping, but not for implementation in V8. [15:31:34.0426] actually, that document describes a different shape of the embedder API than the design doc [15:31:41.0500] let me update that 2024-03-14 [09:23:41.0442] I thought web integration was needed to be worked out at stage 2.7 as well. But https://tc39.es/process-document/ mentions that host integration should be investigated at stage 2 [11:40:53.0866] well, I thought so too, but IIRC something went to Stage 2.7 last meeting with the idea that host integration is not needed until Stage 3 [11:41:07.0478] I'll ask in another channel [11:43:56.0352] I mean, host integration *is being* investigated [11:44:47.0054] the entrance criteria for 2.7 or 3 doesn't mention host integration, so I'd assume this is something that can continue during those stages? [11:45:20.0830] it has definitely been enforced as a requirement for Stage 3 in the past [11:45:50.0359] it isn't in the process doc because the relationship between TC39 and the web platform defies consensus [11:56:15.0976] I think we might be overdue for an update anyway, so we could have an "update or stage 2.7" slot [11:57:10.0277] I'm not a fan of those ambiguous titles. Stage 2.7 is a huge deal. If we want to ask for it, let's ask for it, not say "or". The committee can say no, and then it's just an update. [11:57:43.0944] we are definitely overdue for an update. If we decide not to propose it for 2.7, we should put an update on the agenda [11:58:14.0420] in reality the proposal has changed very little since last time, but still, the context has changed, and it's good to keep the energy up around it 2024-03-15 [06:25:57.0796] For this particular proposal, I think I'd want to see host integration specified prior to stage 3. Off hand, this feels like ShadowRealms, where the host integration is a potential can of worms and it would be great to see the DOM side of things as soon as possible. [06:27:37.0050] Since 2.7 signals ready for testing, and I'd want to see tests for DOM APIs as well, I think the host integration part needs to be specified prior to 2.7. [10:14:11.0715] dminor: OK, are you saying that you'd prefer that we have a proposed answer for which AsyncContext.Snapshot is used when calling callbacks from each DOM API, before Stage 2.7? [10:14:59.0440] If you'd like to see that ordering, I wonder if we could ask for consensus on the JS side of the design, even if it's without actual stage advancement. [10:15:46.0093] The idea is we'd have DOM tests by Stage 3, definitely, either way. Having the final DOM specification before or after 2.7 doesn't change that, I think [10:15:58.0466] * The idea is we'd have DOM tests as an entry requirement Stage 3, definitely, either way. Having the final DOM specification before or after 2.7 doesn't change that, I think [10:20:45.0432] I'd like to see the DOM API fully specified as soon as possible, so I can get feedback from DOM engineers. [10:22:04.0834] In this case, I think it's important to have the DOM side fully specified before entering Stage 2.7, to avoid a situation like with ShadowRealms, where we didn't realize until implementation time the full impact of the proposal on the DOM side. [10:22:33.0023] OK, thanks for clarifying! [10:22:42.0065] No problem :) [10:22:43.0541] I'm happy with this conclusion 2024-03-18 [12:59:21.0925] It seems our meeting time has changed to 1pm EST because of daylight savings change [12:59:35.0750] Are we sticking with that, or do we want to adjust it back? [12:59:43.0802] As is, I can't attend 1pm meetings do to conflicts [15:36:12.0706] In my case I can't do 11am PDT this week, so the new time actually works better for me (and mark) [15:36:44.0704] That said mark and I are pretty taken by other priorities, so it may be difficult for us to join anyway [15:40:52.0551] * It seems our meeting time has changed to 1pm EDT because of daylight savings change [15:41:10.0878] Wouldn't it be 10am for you (or 9am if we change it back)? 2024-03-19 [19:20:41.0512] One hour earlier works for me. But it would be difficult for me to join if the call is moved one hour later. [19:27:10.0577] I dunno. Right now I see the invite at 10am PDT which is the original time I suppose [19:28:32.0311] Yeah, I found there were updates to the invitation but the time was not changed. [20:05:53.0705] Right, I'm asking to move it 1hr earlier: https://everytimezone.com/s/677e7747 [20:06:19.0681] We hit daylight savings, and what was a 12pm meeting for me turned into a 1pm meeting. [20:14:31.0364] Sounds good to me to move it 1 hour earlier [20:18:27.0621] Done [20:44:50.0845] PS, added https://github.com/tc39/proposal-async-context/issues/75#issuecomment-1984151672 to the discussion topics [23:10:42.0107] > <@legendecas:matrix.org> Sounds good to me to move it 1 hour earlier Europe is still on winter time, so that would be 5 PM CEST this week, which might make it a bit hard for me to be there on time today [23:11:02.0254] since I have a meeting before that which could go longer [23:13:16.0117] that meeting is anchored to Europe time, so that won't nbe a recurring problem [09:50:40.0974] Notes today: https://docs.google.com/document/d/1WJpNPg9j7h9CKSd3NmlNmivOHDtQ-LGP7mJcwDvNLa8/edit [10:16:39.0945] What's the best way to keep up to date with the information needed to attend the AsyncContext meeting for someone who doesn't have access to the TC39 event calendar? [10:17:42.0687] I tried to just copy the event entry to my own calendar event and invite others who needed to know, but the information is clearly too dynamic for that to work. [10:29:25.0931] We can add you to the official event [10:29:50.0659] Add sdh@google.com [10:50:21.0801] Done. Sorry about the confusion. Your own cal invite _would_ have worked except for the original not accounting for daylight savings. :grimmace: [10:53:28.0555] Got it, thanks! [11:05:25.0876] Thanks, Justin! [11:55:53.0706] Why don’t you have access to the TC39 calendar? [11:56:38.0030] Anyway more broadly we are hoping to give an update on AsyncContext next TC39 meeting, so that will give you a chance 2024-03-29 [03:31:16.0454] I'm starting to get the feeling that the different use cases for AsyncContext are actually so different that for some things it won't be possible to find a behavior that works for all of them [03:32:16.0113] APMs need different things than something like the `console.log` example would need, which are also different from what task attribution needs [03:33:28.0277] in particular, task attribution doesn't really care about registration, it cares about the event loop task that caused the current event loop task to run [03:34:01.0878] and that doesn't even map to async continuation, it just so happens that for promises, you tend to call `.then` or await them immediately after creating/receiving them [03:37:19.0205] use cases which so far relied on zone.js would want a mostly registration-time context for DOM events, but that doesn't work for APMs [03:37:28.0418] I'm not sure there's a solution [03:39:01.0596] * APMs need different things than something like the `console.log` server platform example would need, which are also different from what task attribution needs [03:43:00.0431] for events I guess you could opt into some behavior in the event registation, but this also affects observers and generators [09:38:26.0850] do you have a concrete case where their needs are divergent? [09:38:38.0392] * do you have a concrete case where their needs and definition are divergent? [09:44:18.0044] Well, the various `XMLHttpRequest` events are fired with the context active at the time `send` was called [09:44:46.0811] this is different even from task attribution's behavior with `fetch`, which is at async continuations (equivalent to `addEventListener`) [09:45:57.0817] this is why I suspect that they don't actually need the async continuation behavior, and the context in which `fetch` was called might be better suited for that [09:46:20.0915] but it just happens that most code won't see the difference for promise, whereas it might for events [09:50:49.0970] because events tend to be registered for multiple uses, which increases the likelyhood that the registration has a different context than the immediate async cause [11:34:09.0963] So Zone.js uses call time context instead of registration time? [11:39:15.0929] No, Zone.js seems to use registration time for every event [11:40:02.0512] Oh, you said task attribution uses registration time [11:40:18.0519] * Oh, you said task attribution doesn’t use registration time [11:40:37.0454] If I said so, I meant the opposite [11:40:52.0991] > in particular, task attribution doesn't really care about registration, it cares about the event loop task that caused the current event loop task to run [11:41:10.0000] Maybe I misunderstand [11:41:28.0197] (Or I confused you with my edit) [11:41:29.0663] FWIW, registration time by default makes it a lot harder to maintain the cause's context, whereas cause-by-default can restore registration time with a simple call to wrap. [11:42:14.0541] > <@jridgewell:matrix.org> (Or I confused you with my edit) That, and I'm currently in the middle of walking my dog 😅 [11:43:37.0441] So for attribution, if I do `el.addEventListener(‘click’, () => {})`, they want to propagate the context that happens during the trigger? [11:43:54.0925] > <@abotella:igalia.com> That, and I'm currently in the middle of walking my dog 😅 SEND PICS PLZ [11:54:12.0845] > <@jridgewell:matrix.org> So for attribution, if I do `el.addEventListener(‘click’, () => {})`, they want to propagate the context that happens during the trigger? Task attribution doesn't seem to care too much about most events, since it's not something that can be queried by the user. The default is call-time, and that's the case for the click event [11:55:00.0393] So `el.click()` (which fires the event synchronously) uses the call-time event, and clicks coming from the user are fired in the empty context [11:55:13.0909] * So `el.click()` (which fires the event synchronously) uses the call-time context, and clicks coming from the user are fired in the empty context [11:55:24.0231] > <@jridgewell:matrix.org> So for attribution, if I do `el.addEventListener(‘click’, () => {})`, they want to propagate the context that happens during the trigger? * Task attribution doesn't seem to care too much about most events, since it's not something that can be queried by JS code. The default is call-time, and that's the case for the click event [11:56:31.0654] The only things which are registration-time in task attribution are web APIs which schedule a callback: `setTimeout`, `requestAnimationFrame`, `scheduler.postTask`... [12:05:58.0290] So a coulple of questions: - Is call-time behavior necessary for Task Attribution? (Probably yes?) - Do we feel that registration-time is correct for AC? (I think so, but could be persuaded) [12:06:49.0143] If we don’t match Task Attribution’s semantics, then we cannot share the same CPED pointer in the job records [12:07:13.0324] We’d need to reevaluate our performanc/memory impact since we’d need a new pointer [12:07:23.0789] * We’d need to reevaluate our performance/memory impact since we’d need a new pointer. [12:08:41.0328] > <@jridgewell:matrix.org> If we don’t match Task Attribution’s semantics, then we cannot share the same CPED pointer in the job records It could be shared if the code in Blink that sets the propagation has task attribution in mind, but that would mean turning what would be `AsyncContext.Snapshot.p.run` into an `AsyncContext.Variable.p.run` [12:08:47.0688] which would have memory and performance effects [12:10:31.0187] I don’t understand, how would that work? [12:11:21.0908] Would the `click()` restore the snapshot, then run a `taskAttribution.run(callTime, …)`? [12:11:41.0517] yeah [12:12:50.0492] Ok, that’s not terrible [12:13:10.0348] If we had a fixed key slot for attribution, we could make that reasonably fast [12:13:25.0617] Instead of storing attribution inside the HAMT with the user variables [12:14:50.0225] > <@jridgewell:matrix.org> So a coulple of questions: > - Is call-time behavior necessary for Task Attribution? (Probably yes?) > - Do we feel that registration-time is correct for AC? (I think so, but could be persuaded) about 1, I asked Scott Haseley last week, and these were his initial thoughts [12:14:56.0675] > It might be okay, but I'll need to think about it and discuss with the team -- and some folks are out this week. Initial concerns/uncertainties: > - This could impact soft navigation because code running within a soft nav task-attributable task will have a different context, e.g. an event fired within a click or setTimeout. Is this okay (not sure)? Either way it could change reported soft navs, so we'd need to run experiments (assuming the soft nav context isn't automatically plumbed through). > - We previously created a new TaskScope for every event/callback, which we changed because of performance issues, so we'd need to be really careful here. [12:15:39.0607] `TaskScope` is the equivalent of a `Variable.p.run` [12:24:01.0967] Ok, worse case we could add a host-hook before we set the context when restoring a snapshot [12:24:20.0491] That way engines could perform whatever call-time modification they n eed [12:24:22.0498] * That way engines could perform whatever call-time modification they need [12:24:44.0706] Though now I’m curious when they don’t need a new `TaskScope` [12:27:22.0334] > <@jridgewell:matrix.org> Ok, worse case we could add a host-hook before we set the context when restoring a snapshot I think the only chance that this might be needed for task attribution is if whatever we end up deciding for generators doesn't end up working for them (which I doubt will happen) [12:27:44.0226] because they're fine with the CPED behavior, and anything else would be Blink calling the V8 embedder API [12:28:16.0898] I think the ordering is incorrect, which will require it [12:28:50.0588] Actually, no, for regular `addEventListener()` they should be fine [12:29:11.0237] I was thinking we did `AC.wrap(listener)` on the V8 side, but we don't [12:29:37.0737] But, how would Attribution work when I invoke a `snapshot.run(foo)`? [12:30:10.0344] Should the current `TaskScope` be kept, or is it ok to restore the snapshot’s? [12:31:17.0979] When I talked with Yoav Weiss, the conclusion was that it would be fine to restore the snapshot's, because that is already a thing you can do with promises, although it's obviously not as accessible [12:31:22.0757] but I haven't discussed this with Scott [12:48:51.0280] Unrelated (so maybe respond in a thread): have we thought about dynamic import (with top-level `await`)? In particular, does the imported module run in the context of the importer, or in the root context? [12:49:46.0502] huh, I hadn't thought of that [12:50:09.0503] task attribution does something for script and module evaluation, but I haven't looked at it in any detail [12:51:52.0668] We discussed that a bit in the SES meeting, I think they were expecting it to run within the context of the importer [12:52:05.0228] That’s my thought as well [12:57:10.0473] That probably makes it difficult to polyfil, huh? [12:59:02.0961] if we end up having things in the web integration that aren't exactly call time or registration time, but instead some async originating context, that would probably be impossible to polyfill [12:59:56.0370] It would require bundler integration to do properly [15:36:39.0954] > <@abotella:igalia.com> I'm starting to get the feeling that the different use cases for AsyncContext are actually so different that for some things it won't be possible to find a behavior that works for all of them OK, this is possible, and people have claimed it, but for me to understand it better, it would help me to see concrete examples of where different behavior would make sense for the same callback, depending on the context. Are you working on collecting any examples like this? [15:37:23.0271] something I've heard claimed is that certain variables make sense to treat in different ways than other variables [15:38:38.0050] anyway if it turns out that this is intractably bad, we can withdraw the proposal (it has been raised as a counterargument before), but I'm not at all convinced that the requirements for different environments are different. [15:38:54.0280] I'm not arguing at this point that this is intractable [15:39:13.0230] could you characterize the difference in any more detail? [15:39:14.0083] but I'm fearing that it might be the case [15:39:26.0362] right, so, I'd like to understand what's behind that fear [15:42:33.0425] I think it'd be helpful if we had a table of different functions which take callbacks, and then we can think about various different policies for which snapshot they should restore. You had something like this in progress, right? Were there any particularly challenging "rows" that you encountered? [15:43:16.0494] well, for every single event, task attribution's behavior is different from zone.js's [15:43:33.0607] could you give a concrete example and we can think through what's useful? [15:48:44.0395] the example that made me realize that task attribution's use case is probably quite different from most users of AsyncContext is that task attribution recently made the `XMLHttpRequest` events have the context of the `send()` call [15:49:12.0812] whereas before it just had an empty context (which is the default for async events in task attribution) [15:49:24.0232] note that this is different from fetch [15:49:28.0390] even in task attribution [15:49:34.0098] OK, so let's think about XMLHttpRequest and fetch. What are the semantics in zone.js and task attribution of each? [15:49:55.0569] we should probably add AsyncLocalStorage's semantics as well to that list, at least for fetch [15:50:15.0055] oh I guess fetch doesn't have a callback so this doesn't come up? it's just from promises? [15:50:21.0398] yeah [15:50:53.0878] I would very much not assume that either of those two implementations (zone.js or task attribution) is perfect and has semantics that we must preserve exactly as they are. We should think about what is important about their behavior for their users. [15:51:07.0513] they are just reference points that are useful in an investigation [15:51:22.0632] yeah, and indeed I think task attribution is not perfect here [15:51:27.0576] at least for what I think they need [15:51:38.0725] (also XHR is legacy; it would somehow be easier to think about something which isn't so deprecated) [15:52:02.0865] well, the fact that this was different in XHR and fetch was what made me realize the different semantics [15:52:15.0400] OK, what are the semantics of each, in each framework? [15:52:35.0977] oh I see you explained in a thread [15:52:42.0929] https://matrix.to/#/!eQuZUAhGqudVFPodUG:matrix.org/$MWb8YUBP-AfcdHf9n2LVI-EIbo390545jUohOKlSZ6Q?via=matrix.org&via=mozilla.org&via=igalia.com [15:53:27.0852] since fetch returns a promise, ALS, task attribution and zone.js all propagate the context at the point that the promise is awaited or called `.then()` [15:53:43.0399] not the context at which `fetch()` is called [15:54:26.0696] in XHR, calling `fetch()` would be equivalent to calling either `open()` or `send()` – it doesn't really matter which, but task attribution uses `send()` [15:54:34.0030] and that is the context that task attribution propagates [15:54:45.0480] let's just focus on XHR onto itself. Is this consistent between zone.js and task attribution? [15:54:56.0741] no, zone.js uses the registration-time context (for `addEventListener`) [15:55:42.0790] So, let's think, when do we expect these contexts to differ? [15:56:26.0727] we've already made calls in this proposal that it's OK for us to change semantics slightly if we expect the contexts to be equal in practice (e.g., for unhandled promise rejections) [15:56:52.0552] I think, with XHR, you tend to create it, add the events, and send it all in one piece of JS [15:57:31.0352] IIRC the `XMLHttpRequest` object can be reused for multiple fetches, but it tends not to be [15:57:59.0285] and this is very different from something long lived like a DOM element, document, window... [15:58:20.0448] I wonder if we can find any old zone.js bug report/incremental development around this. I'll ask my Angular contacts. [15:58:28.0872] Have you run into anything else besides XHR? [15:58:42.0205] setTimeout is unambiguous, for example, right? [15:59:15.0006] yeah, for web APIs which schedule a callback, there is only one possible context that could be used [16:11:45.0905] OK, I suspect that this particular case is one where either answer would be fine... it'll be good to dig into another one once we think of it [16:12:56.0445] I think I should focus on which possible contexts would make sense for each event, rather than on what task attribution or zone.js do [16:13:32.0397] I suspect that's more likely to give us general rules [16:14:00.0068] I agree; those two are interesting reference points to keep in mind, but we're not going for 100% backwards compatibility with either. [16:14:18.0656] I suggested looking at those because they represent some accumulation of knowledge/experience in this area [16:14:50.0347] I think it’s still useful to consider which context Zone.js uses for each API [16:15:07.0614] We don’t need to be 100% compatible, but we should have a good reason for breaking with it. [16:15:08.0089] zone.js's behavior seems to be to use registration time on every event, except that it allows overriding the behavior for different events [16:15:22.0222] although it's not fully consistent in that [16:15:48.0860] It would be easier for me to understand these descriptions of what zone.js does based on concrete examples, and what we think of them [16:15:52.0197] (i.e. `MessagePort.p.onmessage` is call-time, but the `message` event on `MessagePort` is registration-time) [16:16:11.0872] Even if it’s always registraiton time, we still need to list out each of the APIs we expect will integrate with AC [16:16:21.0381] also what kind of overriding they allow (we have AsyncContext.Snapshot.wrap for certain kinds of overriding, but I'm not sure whether or not this models everything) [16:16:33.0164] That way we can discuss with the Shu and Dan Minor [16:16:54.0283] > <@jridgewell:matrix.org> Even if it’s always registraiton time, we still need to list out each of the APIs we expect will integrate with AC yes, either that or make a uniform change in WebIDL. But I think we should list out many APIs to make sure we're specifying the behavior that we want to actually happen. [16:17:24.0232] the ideal case would be something that's uniform in some way or other. I just don't know what that policy is (people have posited directly contradictory general rules), and I think we will be able to derive this best from examples. [16:17:50.0360] > <@littledan:matrix.org> also what kind of overriding they allow (we have AsyncContext.Snapshot.wrap for certain kinds of overriding, but I'm not sure whether or not this models everything) it seems like you can list a set of event names which shouldn't be registration-time [16:18:12.0728] > <@abotella:igalia.com> it seems like you can list a set of event names which shouldn't be registration-time yep, that's one possibility! and this can be expressed in WebIDL with things like extended attributes. [16:18:42.0045] but first is figuring this out through concrete examples. Something can look scary in the abstract but then prove to be small/easy when you examine it concretely. [16:19:06.0243] or, "obviously" one way in the abstract, when under concrete inspection, it is clearly wrong 2024-03-30 [20:31:07.0206] > <@littledan:matrix.org> also what kind of overriding they allow (we have AsyncContext.Snapshot.wrap for certain kinds of overriding, but I'm not sure whether or not this models everything) Along these lines - if there's not a clear choice between registration-time and some other context, then it may be worth remembering that you can always get the registration context using wrap no matter what option is chosen, but if the spec is to go with registraion context, then the other option is likely much harder to achieve in the use cases where it may be needed. [04:02:07.0807] > <@stephenhicks:matrix.org> Along these lines - if there's not a clear choice between registration-time and some other context, then it may be worth remembering that you can always get the registration context using wrap no matter what option is chosen, but if the spec is to go with registraion context, then the other option is likely much harder to achieve in the use cases where it may be needed. I’m aware of this argument but I am not so sure we should weigh this “expressiveness” argument too highly in all cases. I expect most usages in application code to just take the default behavior, so getting that “right” seems like the overwhelming factor (unless there is a strong expressiveness motivation for a particular case).