diff --git a/meetings/2025-05/2506_d9of4.jpg b/meetings/2025-05/2506_d9of4.jpg new file mode 100644 index 0000000..20bdccf Binary files /dev/null and b/meetings/2025-05/2506_d9of4.jpg differ diff --git a/meetings/2025-05/2506_l147s.jpg b/meetings/2025-05/2506_l147s.jpg new file mode 100644 index 0000000..468dfdb Binary files /dev/null and b/meetings/2025-05/2506_l147s.jpg differ diff --git a/meetings/2025-05/2506_p2lwb.jpg b/meetings/2025-05/2506_p2lwb.jpg new file mode 100644 index 0000000..3383782 Binary files /dev/null and b/meetings/2025-05/2506_p2lwb.jpg differ diff --git a/meetings/2025-05/may-28.md b/meetings/2025-05/may-28.md new file mode 100644 index 0000000..fef905f --- /dev/null +++ b/meetings/2025-05/may-28.md @@ -0,0 +1,1550 @@ +# 108th TC39 Meeting + +Day One—28 May 2025 + +**Attendees:** + +| Name | Abbreviation | Organization | +|---------------------|--------------|---------------------| +| Ujjwal Sharma | USA | Igalia | +| Ross Kirsling | RKG | Sony | +| Waldemar Horwat | WH | Invited Expert | +| Rob Palmer | RPR | Bloomberg | +| Daniel Minor | DLM | Mozilla | +| Daniel Rosenwasser | DRR | Microsoft | +| Gus Caplan | GCL | Deno Land Inc | +| Duncan MacGregor | DMM | ServiceNow Inc | +| Christian Ulbrich | CHU | Zalari | +| Zbigniew Tenerowicz | ? | MetaMask | +| Tom Kopp | TKP | Zalari | +| Tooru Fujisawa | TFA | Mozilla | +| Jack Works | JWK | Sujitech | +| Jesse Alama | JMN | Igalia | +| Dmitry Makhnev | DJM | JetBrains | +| Oliver Medhurst | OMT | IE (Porffor) | +| Tab Atkins-Bittner | TAB | Google | +| Jonathan Kuperman | JKP | Bloomberg | +| Eemeli Aro | EAO | Mozilla | +| Richard Gibson | RGN | Agoric | +| Chengzhong Wu | CZW | Bloomberg | +| Steve Hicks | SHS | Google | +| Mikhail Barash | MBH | Univ. of Bergen | +| Yusuke Suzuki | YSZ | Apple | +| Chip Morningstar | CM | MetaMask | +| Yulia Startsev | YSV | Mozilla | +| Istvan Sebestyen | IS | Ecma | +| Philip Chimento | PFC | Igalia | +| J. S. Choi | JSC | IE (Univ. of Utah ) | +| Ron Buckton | RBN | IE | +| Luca Casonato | LCA | Deno Land Inc | +| Samina Husain | SHN | Ecma | +| Andreu Botella | ABO | Igalia | +| Jonas Haukenes | JHS | Univ. of Bergen | +| Romulo Cintra | RCA | Igalia | +| Jacob Smith | JSH | OpenJS | + +## Opening & Welcome + +Presenter: Ujjwal Sharma (USA) + +USA: All right. Looks like my slides are up. I hope I am audible. I am audible in the room. Could I get a quick check from friends online. + +WH: Yes, I can hear you. + +USA: Thank you, Waldemar. All right. Let’s start. + +USA: Welcome. Everyone, in person and online to 108 meeting of TC39. Let’s go over a few details and start the meeting. + +USA: First of all, to all of you here in person, welcome to Coruna. I hope you like our city. There’s three fun facts in know order about Coruna. First is the Torre that you might have seen from everywhere; it's the symbol of the city. TDZ was originally built by the Romans. It’s one of the oldest lighthouses in the world. And the oldest one in—still in operation. Deportivo, the following football team, it’s not impossible now, used to be a spanish football team once. I thought it was a fun fact. And Coruna has been the ancient capital of Galicia and something not locals know is that it was only formally replaced in 2002. + +USA: This is a hybrid meeting which means that we have folks in person and online. And, you know, random details. I can actually fill in with some local logistics still. So if you are still on our network, there’s the access ID and passwords. There’s an accessible bathroom on the other side and kitchen where you can grab a snack. There’s also snacks along the way. And if you haven’t grabbed a tag or need a mask or a test, they’re on the desk outside and that’s it for the local logics. Feel free to tell us if you need help. My personal contact information is also on the reflector. So feel free. + +USA: Yes. So regarding the masking policy. There’s a slide update. We continue with the COVID measures as expected from the previous meeting, we will follow them if you have any concerns regarding them, contact us we would like to do better. Regarding the mask policy specifically, this is the first meeting where we move to not mandatory masking. However, it is still encouraged. + +USA: Let me get used to the chairs group. Here is me and Rob in person. Chris is going to join us online. And Daniel Minor is here—sorry, in person. As the facilitator as well as Justin and Daniel, joining us online as well. + +USA: Make sure to sign in specifically for folks joining online. You should have seen a form like this and filled it in to get to this point. If you haven’t, please fill this out. This helps us keep track of delegates and while you’re at it, feel free to do the delegate survey. Okay. + +USA: So about the code of conduct. This is, you know, a change to our usual policy and quite important. This event, like the previous one that we did, has a dual CoC policy. Both TC39 code of conduct which I believe you are all familiar with and Igalia code of conduct which you are not familiar with, are enforced here. In practice, this means that you have to abide by both of them and may report incidents to either or probably both. Igalia CoC is up in multiple places if you want to scan the code or read about it. And the TC39 CoC is up at the regular place. I do suggest reading these whenever you can, if you haven’t. + +USA: Talking a little bit about the major events, we have one from yesterday, which had already happened. So on Tuesday, yesterday morning, at 10, we had the TG5 workshop, which was well, thank you, for organizing. Today we will have two things: so first at 6, we have the guided city to your. At the plaza in the centre of the city. If you don’t know where that is, ask. I would be happy to take you there. And later, at 9, we start with the social dinner. The location for all of these is shared on the reflector, but feel free to ask. + +USA: Tomorrow, we have a really fun community event planned for you. If you signed up for it already, thank you so much. If you haven’t, and you are free around the time, please join us. I think it will be really interesting and insightful for the local community to meet us. + +USA: Moving on, here is the daily schedule that we are going to abide by for the three days. The meeting is at 10, two above that, the doors open at 9. The breakfast starts around 9:30. We are going to break at 12, for lunch. For an hour. Until 13. And go for another two hours. Until the mid-afternoon break, and the meeting ends at 17. So 5 p.m. if you follow the 12 hour calendar and the building—well, the office closes at 6. So you may want to hang around, but if any of it falls outside of the schedule, please let us know. + +USA: A quick overview of the comms tools for our meets for newcomers and reminder to the older delegates. We have TCQ this the entire meeting. We will have the entire schedule here soon. Then you have the participant view, which looks like this. You have the topic, who is speaking and a bunch of the buttons. They all do different things. And then the speaker view, which has one extra button. Going over the button, increasing from order of urgency, so basically saying, that you want to add a new topic. You want to discuss a new thing without any sense of urgency. It adds you to the bottom of the list. Discussing the current topic puts you at the top of the list. You want to discuss the current topic that’s being discussed at the moment. Clarifying question, at the top of the queue. This is a way to interrupt softly the ongoing discussion and ask a clarifying question that might help with the rest of the queue. Point the order, in red at the top of the queue and this is used only for, you know, stopping essentially and if you think that something is a miss, you have no notes, if you can’t—off-line, use this, but reframe from overusing. I am done speaking button. This is, you know, a terrible button. Please don’t use it. It’s tempting to press it. Please don’t press it. + +USA: Then the matrix chat. You are not on matrix, join us. That’s where we discuss everything async and during the meeting, TC39 and TC39 delegates or official chat or technical chat and template dead zone for banter and everything offtopic and there’s more, more specific chats. Please join the TC39 space to check out all of them. A reminder to folks in person, if you are not part of matrix group for the in person considered nation, ask me for invite or join it. It’s on TC39 space. It’s a useful room for the next couple of days. Talking about the IPR policy. I am not a lawyer. But yours should have gone through it. But to reiterate a time by part of the meeting, in this room, we are all assumed to have signed this IPR policy. Either your employer signed this for you or you have signed it as an individual. If you haven’t or don’t believe they are—something applicable to you, please talk to us most immediately. And it doesn’t apply to observers. So observers are welcome to observe. But as a result of this, it should not be able to contribute anything to the meeting. + +USA: Then we have notes. So I believe the notes are already online and being transcribed. We would ask you to help us out with them. But most importantly, after you finish with any of your topics, please summarize key points or give conclusions that help us make the notes more useful to the general public. And there is a blurb that I am speaking to say out loud at this point. A detailed transcript of the meeting is being prepared and on Github. You may edit this at any time during this meeting in Google Docs for accuracy, including deleting comments which you do not wish to appear. You may also get corrections or deletions after the fact by editing the Google Doc in the first weeks or making a PR in the notes for contacting the TC39 chairs correctly. Thank you. + +USA: Talking briefly about the next meeting. It’s the 109th meeting remote. It’s going to be in exactly a month-endize from—two months from now. Pretty standard. 28 to 31 July. 4 days. Online and in the Pacific daylight time. + +USA: Okay. Now, the—no. At the committee housekeeping part. First of all, we like to approve the previous minutes of, I believe, you might have gone through them, they have been merged. The notes from the last meeting. It’s been like a month since we had it. So yeah. Do any of you have comments? Either in person or online about the previous minutes? No. I assume we approve the previous minutes. + +USA: Now, let’s give another minute to adopt the current agenda. Any concerns or late editions? No? All right. Then—all right. So we have time if there are any topics that you’ve been holding off on or, you know, think would be worth raising to the committee, a productive use of our time, especially, you know, during the afternoon we could do breakout sessions or something. Although, we could have that time for continuations. All right. Now, it’s time for us to do the uncomfortable thing. Ask for note-takers. Please. Thank you. So Christian, John, and Oliver. Right? Okay. Thank you. Three volunteers right away. We are doing great. Thank you, everyone. + +USA: All right. Now, I hand it over to Samina. + +## Secretary’s Report + +Presenter: Samina Husain (SHN) + +- [slides](https://github.com/tc39/agendas/blob/main/2025/tc39-2025-020.pdf) + +USA: Two more things. One the microphone has to be relatively close to you while speaking. So you know, if somebody mentions that you are not audible or feel that, you know, from the feedback in the room that you’re not audible enough, please try to be closer to the microphone. The exact heuristic that we measured was, like, if you can touch the microphone in your hand, your mouth, and the last thing is, the camera, the camera is a bit smart. It tries to guess who is speaking and tries to put them in the frame. If you would like to be in the frame, and you aren’t, you can try to speak up. But if you are presenting, we would also recommend just using your front camera for that, if you would like. That’s it. Thank you. + +SHN: Thank you Igalia for hosting this meeting. Beautiful location. And a great setup here. And I am really looking to the social events. I’m sorry I missed yesterday’s TG5 workshop. It’s good to have participation and the community event coming up will be quite active. So that’s great for this community and for ECMA.I have a very short update today. I do have a longer slot on the agenda tomorrow to present about the ECMA framework and I will focus on those topics tomorrow. Today I will do the usual update. AKI and I are supporting this committee together. She will be back by the next meeting. + +SHN: Just a quick overview. It seems we just had our last meeting a few weeks ago, but it’s almost been eight weeks. But a lot has happened. Focus on ECMA262 and ECMA402 the editions are just about ready. The opt-out period will end very soon and I will also give a short update with a new TC and my annex has the usual information to look at. The opt-out review for 262 and 402 has already started some time back, it ends on Saturday, that’s May 31. So far there’s no issue, traditionally there hasn’t been anything. I assume the next few days will go smoothly and both editions will be ready for June 25th GA. Perfect. Thank you for all of that work. I think Aki will prepare the PDF and perhaps already got most of it done. I think that’s excellent. + +SHN: TC57. A number of discussions on this TC. The original topic was brought up by Daniel. Other members were also involved. We had an ExeCom meeting a couple of weeks ago to discuss this. And I appreciate the support that we had from TAB, from Google and JMN from Igalia to make sure we had everything well understood and that the questions that the ExeCom may have on this topic were addressed. So it’s good news we would like to move forward with TC57. The schema languages, you see the scope written and the program of work on the slide. There are a couple of things I still need to do. I will work with TAB and JMN to get more guidance. We want to make sure JSON and the KDL committee are aware of how to move forward and also well aware of what we need to do regarding the RF royalty free, and any IPR topics that we want to ensure aligns with the ECMA rules and regulations. I do understand that is moving forward and that’s not a show-stopper. But the action lies with me, which I will have to do before the June 25 meeting at the GA in which we anticipate to approve this. So again, it’s great that we have this new TC. It’s been a number of discussions to make sure we are not overlapping any other work from any other group. And that it is something that both the committees want to do. That is a good step forward and I will keep engaged on this. + +SHN: As per usual, I will continue to look at the invited experts. I always do it as a reminder at the end of the third quarter, I will review the complete list. We don’t remove anybody. It’s rare. I like to go back to individuals who do represent organizations to see how they are and if they are ready to join with their interest and work with TC39. + +SHN: W3C, I always remind people of their horizontal review if anyone has interest in doing that. I should point out that the W3C has started a new community group on AI. I will reach out to talk about that because Ecma also started—a technical committee, TC56. Ecma introduced this officially this spring on AI agents. I will reach out to W3C on that. We have a bit more collaboration ahead of us. + +SHN: I think we have gone through the code of conduct and invited experts, summary and conclusions are relevant. So I appreciate everybody’s effort on that. We did well at the last meeting and AKI was very good at getting it all organized. The document list is on my annex. I will jump to it. There’s a bunch of documents we've worked on since our last meeting. If you have any interest to understand more about the latest documents both from a GA perspective and a technical committee just let your chairs know and they will provide the information. The next meetings are set, already mentioned by USA. What is important is the next meeting coming up for the general assembly. June 25-26 meeting. The approval of the next editions. Please keep in mind the ExeCom, reviews new topics, also about standards that need to be approved. If there are other standards, members here in this group that are involved in other technical committees to remind you of the dates of the ExeCom that are important and of course the chair’s report is always reviewed there. Dates are published for the next year. So as you book—plan your next meeting for TC39, keep these dates in your planning. + +SHN: And that is the end of my short update. I am open for any questions. + +### Speaker's Summary of Key Points + +A brief update was given, where highlights included progress on ECMA-262 and ECMA-402, which are on track for General Assembly approval in June, pending the close of the opt-out period with no issues expected. + +The formation of a new Technical Committee, TC57, focused on schema languages, was also addressed. The support from TAB (Google) and JMN (Igalia) was acknowledged for clarifying concerns and outlining the remaining steps, including coordination with stakeholders to ensure compliance with Ecma’s Royalty-Free (RF) IPR policy. + +Additional comments included ongoing review of invited experts, upcoming collaboration with W3C, particularly on AI, and a reminder of the code of conduct and document access. + +Finally, dates of the upcoming General Assembly and ExeCom were noted to plan accordingly for technical committee activities. + +RPR: Sorry. No questions. I realize I only just opened up TCQ on the correct item. You are welcome to go on to the Q&A. If there are any questions, SHN. + +SHN: Great. If you can always approach me outside or anywhere and also tomorrow I will do a presentation at the ECMA framework. I hope that will be a very positive discussion to bring you up to speed on where we are and the things we are doing together. Thanks. + +USA: All right. Thank you, Samina. Next up we move on to the ECMA262 editors updates. + +## ECMA262 Status Updates + +Presenter: Michael Ficarra (MF) + +- [slides](https://docs.google.com/presentation/d/1SrO2NdgSdWdZ9dCYRFvxnpOhTz94aXmn5ccGeecF2gs/edit) + +SHN: Just to comment, earlier we talked about the IPR. Don’t assume anything, if unsure you don’t have a royalty free signed off by yourselves or organization, just double-check. And let me know or let the chairs know. It is important. So don’t make any assumptions. Thanks. + +MF: Okay. Everybody's favorite part of the meeting. Editor’s update. A lot has been done. But not much you are going to care about. So we have the one normative change which is the pull requested introduced by NRO at the last meeting. You should remember it. But it should have no actual impact. This was questionably marked as normative. And nothing editorial that any of you need to concern yourselves with. We did update our editorial work section to better reflect what our actual plans are. I think the only one that anyone here might care about is the optional parameters mostly going away where it makes sense for them to. We are trying to reduce that. We would like to remind everyone that there are keyboard shortcuts, ECMA262 and anything generated by Ecmarkup, proposals as well. Question mark, it gives you the help dialogue. So you can use those. And that’s it. + +USA: Topic by Nicolo in the queue. + +NRO: Yes. I started pulling structuredClone on the list of things. Nothing actually is exposed in any way. + +MF: Yeah. We want the infrastructure for it to be in 262. + +USA: That was it for the queue. Thank you, MF. + +USA: All right. Then, let’s move on. I am next. + +## ECMA402 Status Updates + +Presenter: Ujjwal Sharma (USA) + +- [slides](https://notes.igalia.com/p/GhteY-6ME) + +USA: All right. Share my screen real quick. It looks like it works. Can you see this? Yes. All right. Hello, everyone. I don’t know why I make slides for this. But I guess it’s good to convey this information. Hello. This is the 402 status update. We have two editorial improvements. First we marked the default locale as an exact operation as a fingerprinting. 997. And we eliminated the use of this tag. It says, EMU normative optional. This was done by RKG. Thank you, Ross. And that’s it. That were the two main editorial changes that we made. There’s a few normative changes that you are going to hear from us about in a bit and that’s been all for, for 402. Thanks. + +USA: Nobody is on the queue. All right. Next we have CM. + +## ECMA404 Status Updates + +Presenter: Chip Morningstar (CM) + +CM: So I had every intention of being with you in person in A Coruña. And, in fact, spent the past two days in airports and on airplanes to that end, but American Airlines had other ideas about how the air transport business works and now I am back in California. And anybody who cares to find out more about that can talk to me off-line. + +CM: And what I discovered is that regardless of whether I am in California or A Coruña, JSON has not changed. + +USA: That’s a relief, Chip. But not about your flight. Sorry about that. And yeah. See you later. + +## TG4: Source Maps + +Presenter: Jonathan Kuperman (JKP) + +JKP: Yeah. I can do this update. I don’t have slides. But we just have a very brief update. Which is we are still working on our three main features, which are scopes, embedding the scope information, source maps for debuggers to use, reign mappings allowing a new ability to mark a range inside source map mappings and the debug ID, allowing tools source maps with the generated code at the time. The debug ID proposal includes another magic comment. Which brought us back to the parsing of comments issue that we concluded last year. We are working with removing that ambiguity. We continue to work on those features. + +## TG5: Experiments in Programming Language Standardization + +Presenter: Mikhail Barash (MBH) + +- [slides](https://docs.google.com/presentation/d/1QhITTbFDCmPNFV2U2K-YDsPNyOXTNCPCsTyjwwOZwAc/edit?usp=sharing) + +MBH: Yes. Good morning. + +MBH: So a short update. We had a successful TG5 at the university of Coruña. We continue to have regular monthly meetings, last Wednesday of each month. And, for example, this April we had a meeting about categorizing proposals and observations from proposal statistics and I will have later today a separate topic about this. The next TG5 workshop is planned for the 17th of November in Tokyo at Bloomberg. And I would also like to briefly mention the outreach activities of TG5. The European Conference on Object-Oriented Programming will be held this July in Bergen in Norway. YSV and I are arranging this, and I have here highlighted the topics that might be interesting for the delegates if you would like to attend. Thank you. + +MBH: Thank you. + +## Normative: Add "Late Errors for Function Call Assignment Targets" to Annex B ([\#3568](https://github.com/tc39/ecma262/pull/3568)) + +Presenter: Ross Kirsling (RKG) + +- [PR](https://github.com/tc39/ecma262/pull/3568) +- [slides](https://docs.google.com/presentation/d/1V8QKaDqqAXfuwR3Ymi3blgT_auPalM3ZYXgAjyaLN4U/edit?usp=sharing) + +RKG: Sure. Yeah. This is amazing. Half an hour ahead of schedule. Cool, so good morning to everyone local in Spain. I am here to talk about adding a section to Annex B 3. Everybody’s favorite area of this specification. So this section is, I am proposing to call late errors. It’s time for us to finally address this elephant in the spec. The web reality is that in sloppy mode, using a function call as an assignment target is not an early error like the spec claims it to be. It is a runtime ReferenceError. This affects simple and compound assignments, update expressions, and `for..in` and `for..of`. The one exception is that logical assignment being a relatively new addition to the language doesn’t have this web reality issue. It is always an early error. So that’s cool. + +RKG: The one subtle point is, when precisely the ReferenceError is thrown, you could imagine a world where we—the spec does the least effort thing possible and just let a ReferenceError being thrown when you do a put value. That’s not the case. You can also imagine the option where we know that we are going to try to assign to the result of a function call so we don’t do the function call at all. That’s also not the case. The case is that we throw the ReferenceError immediately after calling the function. And in particular, we don’t resolve the return value to a primitive. Nor do we evaluate the RHS if there is one. My—one of my main reasons for calling this out is that SpiderMonkey has a bug which is that valueOf gets called for `f()++` in spite of the fact that it doesn't for `f()+= 1`. I think this is basically just a discrepancy within SpiderMonkey itself and should be perfectly safe to fix. With that, I have [PR \#3568](https://github.com/tc39/ecma262/pull/3568) that needs your consensus. It follows the new Annex B editorial convention—we are now inserting normative optional blocks into the main body of the spec and then just having a blurb and links to those normative optional blocks in Annex B itself. And the change itself basically amounts to augmenting assignment target type with a new value “web-compat” and using this value in each case to throw a ReferenceError immediately after the function call. + +RKG: So thank you for your attention. And ask you for your consensus. + +USA: Yes. We have Daniel Minor on the queue. + +DLM: Thank you for doing the work to put this together. This makes a lot of sense to me and we support it + +RKG: Wonderful. Thanks, Dan. + +USA: Next on the queue we have MF who says, + 1. This is great. PR is great. + +RKG: Thanks. + +USA: Let’s give it like half a minute more. See if somebody else has a point to make about this. It doesn’t look like it. No. Duncan says, looks good to me. + +RKG: Wonderful. Thank you so much. + +USA: All right. Last call. For any comments. All right. Looks like you have support—oh, no. There’s WH on the queue. + +WH: I can probably guess the answer to this: I assume there are things on the web that are relying on this behavior somewhere? + +RKG: Yes. So the foregoing discussion on Github issues where I finally picked this up to actually do the work, basically everyone was quite pessimistic about fixing this in sloppy mode, or to rephrase it differently, confident that it would break the web to do anything about sloppy mode. But we’re not worried about strict mode. Assuming nothing has changed in Google’s perspective on that matter, yeah. The changes needed for strict mode should be something that we want to do and aren’t worried about negative effect from. + +USA: That was the queue. Let’s give another minute, just in case. All right. That was it. + +RKG: Cool. Thanks, everyone. Have a great meeting. + +USA: Yeah. And thank you, Ross. Would you like to summarize? I think… this one’s fairly quick. But still. + +RKG: Sorry, do you mean in the notes or… ? + +USA: Yeah. You could either dictate a summary here. + +RKG: Yeah. Then, we reached consensus, I believe. Is that… ? + +USA: Yeah, I guess that’s pretty much it. + +RKG: Yeah. + +USA: All right. + +RKG: Thanks so much. + +### Summary + +This discussion was around a PR specifying the web reality that certain errors would not be early errors in sloppy mode on browser-hosted engines. It aligns with the new Annex B editorial convention documented at ([ecma262\#2952](https://github.com/tc39/ecma262/pull/2952)). + +### Conclusion + +- Consensus on merging the presented PR + +## Normative: Added note about sets of locales for web browser implementations needing to not change as a result of user behaviour ([ecma402\#780](https://github.com/tc39/ecma402/pull/780)) + +Presenter: Ujjwal Sharma (USA) + +USA; All right. All right. So about [ECMA402 \#780](https://github.com/tc39/ecma402/pull/780). What is this pull request. And why am I talking about this now? So I would like to give you some information. I believe this is a fairly non-controversial pull request, but let’s see. 780. And the title of the pull request is quite a handful. A mouthful, should I say. But going over it, it says, added a note and it’s a norm active note that’s added here about the sets of locales for web browser implications needing not to change as a result of user behavior. I believe that should do it. But perhaps a little context would be even helpful. + +USA: So this came up back in May 2021, sounds funny to have the dates on, but yeah. This—sorry. This change has something to do with me. I thought it was interesting. Back in May 2021, we were relying on the Intl enumeration apse proposal. There was a request from Mozilla to add a normative node to make sure that while there’s a agreed upon API, which was being useful was being added, there was no accidental change that would be introduced. So the idea was that the entire payload would be shipped essentially. That’s the original issue. It says ships the entire payload and as long as the set of locale shapes was static, we wouldn’t be able to use something like the API for evil. Add beyond that, since this was never in scope for Intl, we agreed and started working on this by May 2023. Since then the PR has been in the works and reviewed. And got a lot of reviews and comments. After everything, we agreed upon wording. The noted self is really small and minor. But the exact words matter quite a bit. We waited for final approvals. Thank you, DLM for helping with coordinating with the folks the SpiderMonkey and we got the final go ahead in May 2025. So a short while ago. And we got TG2 approval timely. Two years jumps for this proposal. Here we are asking for consensus from TG1. + +RPR: Comment from Daniel Minor. + +DLM: Yeah. Thank you for sticking with us. We are happy with the current text. We ran it past our privacy people and YSV has had a look at it. And we support this. + +RPR: Thanks, Dan. All right. So give it a last check. Any objections? We have got neutral from Shane, perhaps. + +SFC: Yeah, I wanted to note this is definitely the exact phrasing and words have been going around for a bit. So I think that we have struck the right balance between documenting the status quo, preserving the user's privacy, as well as giving us room to explore digitally the languages as we move forward. So I support this. + +RPR: All right. So there’s been no objections. And three voices of support. So that is confirmed. We have consensus. + +USA: Great. Thanks, Rob. Moving on, then. I think I have kind of a speed run. Next I have 8 new numbering systems to Unicode 16. + +### Summary + +- The purpose of this pull request is to add language into ECMA-402 that explains expected behavior by browsers to prevent user fingerprinting by tracking available locales + +### Conclusion + +- The original reporters of the issue are satisfied with the language and the PR received consensus to be merged + +## Normative: Add 8 new numbering systems for Unicode 16 ([ecma402\#929](https://github.com/tc39/ecma402/pull/929)) + +Presenter: Ujjwal Sharma (USA) + +USA: So I originally wanted to make slides for this as well. I realized actually in the end, not only were they not super useful, but they were actually less useful than going through the PR. + +USA: So this is a PR that was made by Fran. This is pretty routine for anybody sort of unfamiliar with this. Basically, we need to keep updating the spec for new releases. This one refers to Unicode 16, adding 8 new numbering systems. We do this because we have a table in the spec where we literally list out all of them. + +USA: Actually, no. Let me… here. No. Let me jump to it real quick, then. I am really sorry about that. Sorry. Okay. So here is the list of the currently supported numbering systems. Basically, we keep it in the spec to make sure that there’s no difference between what is shipped across different implementations, but this is, the PR for adding the new 8 systems is a reality in terms of, you know, everyone implementation having moved on to support Unicode 16. This is actually what the PR was waiting on in the first place, as you can see, from 2024, so for a while it was blogged on getting Unicode 16 in. And when it was, it was approved in TG2. So by mistake, it got merged. And we realized that it wasn’t brought to TG1. This is for consensus of updating the list of numbering systems. We will continue to do this. This is obviously a routine thing, as more locale information is introduced, we will update the tables. + +USA: All right. So let’s see. Yeah. Shane? + +SFC: Yeah. This is the reminder, with the committee about the status of this table. It would be nice, if it is synced automatically. But it’s a best-effort basis and we wait until the numbering systems are widely available before we add them to the table. So that’s why you kind of see these pull requests coming in sporadically, once in year in the winter or spring. This is a little bit late landing. So that’s why you see these come in, when they do. So I—but yeah. I support the PR. + +USA: Nicolo? + +NRO: Just a question. They should look at the Unicode spec and follow normative requirement: is our table normative for implementations? + +USA: Sorry. I thought you \[SFC?\] might answer that. But yeah. So this is a normative table. We mention in—well, my screen is still on. Right? In available canonical number systems, you can see while it’s mentioned that the actual algorithm and implementation-defined this is a normative reference to the table. The idea is to have a static set of things like the numbering systems, in this case, that are the minimum sort of support, but obviously as new versions come in, there—this is—this can end be a subset of all of the number systems supported. However, it’s our priority to keep the table updated, but yeah, that reality means that sometimes the Unicode update comes in before we merge the spec. + +SFC: Yeah. The status of this table is that engines can support more than what is in the table, but it’s the minimum for interoperability? + +USA: Shane is that new on the queue or? + +SFC: That was the response to the clarifying question. + +USA: All right. Then I believe that was the queue. I would like to ask for consensus to remind folks of this merged earlier \[unintelligible\], but it was a routine thing. So I hope it wasn’t super interruptive and change anything for any implementor. + +USA: All right. I think without any comments we can call it and move on with the agenda. + +### Summary of key points + +- ECMA-402 needs to regularly update its table of numbering systems to align with the table published by the Unicode Consortium +- It would be nice if this could be automated, but for now it's one pull request per year so no one will be prioritizing that automation + +### Conclusion + +- The PR will be merged + +## Test262 Status Updates + +Presenter: Philip Chimento (PFC) + +PFC: As usual, I will just cover a couple of points with no slides and I will write down the points later in the notes. + +PFC: So the updates that I wanted to cover in this case are that we have been working on landing coverage for several proposals in Test262. Particularly, thanks to RBN splitting up the pull request, we have made progress on coverage of explicit resource management. We have made some progress on landing the test coverage for upsert, or getOrInsert as it’s known now. I mentioned in the last meeting, which we have also formalized in the meantime: It really helps the Test262 maintainers if proposal authors can make a testing plan and share it before writing the tests. That helps us keep track of which parts of a proposal have test coverage already. And it allows us to do review work in smaller chunks so we can check each chunk off the list as we review and merge it instead of reviewing a large 40,000 line pull request or whatever. It’s easier for us to review and merge something that way. And even the tests don't all have to be written before that, just with a testing plan, we know approximately what needs to be covered and look at it in that global way. + +PFC: We’ve landed that in a new guide in the documentation, in the repo, for how to write a test plan and what is helpful for it to include. So if you are writing tests and haven’t seen that, please take a look at it. It should be helpful if you haven’t written a test plan before. + +PFC: The third thing I wanted to cover is that it became clear after discussions that when the committee introduced Stage 2.7, we did not update the requirements around staging tests in stage 2.7 versus 3. The documentation is currently wrong. It says that a proposal must be Stage 3 to have staging tests. And that is not the intention of staging. It should be Stage 2.7. We had some discussions that are still ongoing about at what point should tests be moved from staging into the main corpus, whether that’s during 2.7 or 3. We’ll continue to take a look at that and resolve that question. But please do bear in mind that although the documentation says a proposal must be at least Stage 3 to have staging tests, that’s incorrect. + +PFC: And our other requirement for that discussion is that with the rules around stages, we don’t want to disincentive adding more staging tests during stage 3, if the need arises. That’s what we are keeping in mind. And those were the points that I wanted to communicate. + +PFC: Thank you. Any questions? + +RPR: There’s just one notice. Thanks from OMT on the queue, saying, thank you to Ms2ger for merging the SpiderMonkey tests, even if in staging, it’s helped me find a few bugs, smiley face. + +PFC: That’s very kind of you to say. I will pass that on. I am glad it was helpful. + +### Speaker's Summary of Key Points + +- Coverage has increased of explicit resource management and upsert, among other things. +- Please check the new documentation about writing testing plans, and help us by writing a testing plan for your proposal before submitting tests. +- We are examining the procedures around staging tests and stages 2.7 and 3 in order to update the outdated process documentation. + +## Temporal status update and normative change + +Presenter: Philip Chimento (PFC) + +- [slides](https://ptomato.name/talks/tc39-2025-05/) + +PFC: Okay. So this will be another update on the Temporal proposal. I guess I forgot to introduce myself in the previous item. So I will do it now. I am Philip Chimento (PFC). And I work at Igalia. This work we are doing in partnership with Bloomberg. + +PFC: I am sure anybody who has attended any committee meeting has seen one of these progress updates before. Temporal is the proposal for introducing modern date and time handling into JavaScript. The proposal is Stage 3. It’s been shipped in Firefox, as of yesterday. So it is now out there. This is very exciting news for us. + +PFC: I will have another slide on the progress of other implementations, but in V8 they have started their integration of the Rust library from Boa, [temporal_rs](https://github.com/boa-dev/temporal), and have a partial implementation of Temporal.Instant. And the JavaScriptCore implementation of Temporal is continuing to go forward. temporal_rs is a very interesting library. It’s used as the basis for the implementation of Boa. It’s a collaboration between developers from Boa, V8, and students of the University of Bergen, Norway. We are watching this work with much excitement. + +PFC: So in this update we have one normative change, based on user feedback but I will get to that in a moment. + +PFC: All right. It’s become customary to show one of the graphs every time of the percentage of compliance with the Test262 tests. Now we keep adding tests for edge cases as we find them. The baseline is going to be that the implementation test conformance goes down very slightly as we add new tests for edge cases, and those might reveal bugs in the implementation. So the baseline is conformance going down or staying the same at best. And if there’s work on increasing the conformance, it goes up. + +PFC: We have SpiderMonkey at the top. 99%, which is—as expected. They are the ones that are shipping this without a flag right now. The absolute number to keep in mind when looking at these percentages, there are about 5,000 tests in the repo. Anyway, Boa has jumped up quite a lot as there have been some recent improvements in temporal_rs, the library I just mentioned. JavaScriptCore has jumped up almost a percentage point. My co-worker Tim is working on this, and has a bunch more things in the pipeline to increase the test conformance quite a lot. So If you are a JavaScriptCore reviewer and would like to see this happen, would we use some help getting Tim's work reviewed. Now, V8 has jumped down a lot because they have taken out the old implementation and replaced it with temporal_rs. This is obviously a temporary drop and hopefully they will be up the same as Boa. + +PFC: I want to move to propose a normative change to the proposal. The change will be to UTC offset matching in strings. So the UTC offset part of the string is in bold here. You have a date and a time and an offset from UTC, such as -04:00, and the time zone and calendar annotations. The RFC we used to describe the strings there has no support for having seconds and below in this portion of the strings. You can’t say, -04:00:00.0 or something like that. + +PFC: What does occur, in the wild, other programs emit strings that have that. We do accept it, when parsing. But we never emit it since it’s non-standard. So this is something we discussed in a previous committee meeting the October 2021. It’s been this way for a while. + +PFC: Back then, we discussed that some historical UTC offsets are not whole minutes. Even in the post-1970 era sometimes. So, for example, there’s a time zone that has a -00:44:30 offset that they got rid of in 1972, which is after the start of the computing era. So if we parse a string, where that is the appropriate offset, we accept both the offset with seconds, -00:44:30, and rounded, -00:45. We do not accept the offset with seconds, if about the seconds were incorrect. Such as -00:44:40. And -00:45:01. However, we did previously match it if the seconds were present and 0. And we have gotten feedback from people using Temporal that we should not accept that. If the optional parts are present, they must match. This actually turns out to be a very interesting case. There’s a time zone that changed their offset by 20 seconds in 1952 from -11:19:40 to -11:20:00, even. And both of the offsets are valid at a certain date and time: October 15th, 1952, 1 second before midnight. Previously, it would have been impossible to deserialize this time because if you put in—you wouldn’t be able to deserialize the offset to the change, -11:20:00. If you put in—11:20, it would have matched as the first candidate, -11:19:40. And the same if you included the :00 seconds. They match the first candidate. + +PFC: With this change, we propose changing it so that the seconds were as expected, :00, you mean exactly that offset. We don’t change anything about that matching algorithm used when we—when the seconds are not specified. So -11:20 without the optional parts still behaves as it did before. + +PFC: So this is a lot of fiddly time zone rules to understand, but here’s a code sample showing what changes and what doesn’t change. The behavior doesn’t change if you don’t include the optional seconds. The behavior doesn’t change if you did include the optional seconds and they are correct. It doesn’t change if you include the optional seconds and they’re nonzero and incorrect. And if you do include them and they’re zero and incorrect, then the change is that that will now throw a RangeError because the offset is incorrect for the time zone at that point. And then there’s this special case with Pacific/Niue, where if you include the seconds and they are zero and they are correct, they match the correct candidate offset. So from this very specific string, you will get a slightly different time stamp that matches. + +PFC: All right. That was a lot. Are there questions on this? + +DLM: As of right now, there’s no questions on the queue. But there’s a message from Jason. Thank you to Kevin Ness for leading the development of temporal_rs. + +PFC: That’s very thank worthy. + +PFC: If there aren’t any questions, I would like to call for a consensus on changing the UTC offset matching as I’ve described. + +DLM: Enter the queue, SpiderMonkey team supports this change. + +PFC: Thank you. + +DLM: So you can give it a minute, but it looks like there’s nothing else on the queue. + +PFC: Yeah. We can just give it a short time. + +DLM: Okay. I think you have consensus for this normative change. + +PFC: All right. Thank you very much. I have a summary, a proposed summary for the notes, which I will copy into the notes afterwards. And I think that’s it. And I have even shortened my timebox. So to make it easier to pull something forward from after lunch. + +### Speaker's Summary of Key Points + +- Work on implementation of Temporal in the larger and smaller JS engines continues. + +### Conclusion + +- A change to tighten the requirements on an optional string notation for unusual UTC offsets reached consensus. This change was based on user feedback. + +## Intl Locale Info Stage 3 Update: Normative: Return undefined if direction is unknown + +Presenter: Shane Carr (SFC) + +SFC: This is the item on the agenda. `Intl.Locale` stage 3 update. It’s about the one pull request about text directionality. So I made this little slide. Which you all cannot really see on the—in the room relevant but hopefully on the calm. There’s a link on the agenda. + +SFC: Incident \[unintelligible\] local info gives an API for to get the text directionality, the default directionality of a a locale and it derives from the script of the locale. I have 4 example scripts here. The first is the Latin script. Which is used in European languages. This is used with the Latin script. Left to right. And then top to bottom. I was doing this Nicolo. The status quo. The APIs return LTR for this. Actually, I am jumping ahead of myself. + +SFC: I am going to go ahead and actually pull the `Intl.Locale` info to you can see the spec text involved. I am jumping a little bit ahead of myself. Yeah. This is what happens when you don’t—a little bit late getting this. Here we go. We have this API right here. Which I am showing on the screen. I want to make that super big so you can see it in the room. + +SFC: So this has the gettext info it will return an object with a directionality string. The directionality string is going to be either the string LTR or the string RTL. The problem and the motivation for the problem is not all scripts are LTR or RTL. I am going to go back to the slide now. And then show you what this is. Latin is easy. LTR. Currently LTR on the spec. And we want to keep did that. Arabic is the classic RTL. Keep that way. The thing with this is interesting, is for the Ougr script is written top to bottom and left to right. But in modern analysis, it’s right to left and top to bottom. And Mongolian script is in a similar boat and other scripts vertically, but in modern usage, right to left or right to left. And Unicode gives data for this in the file called script metadata.txt. Which is how the implementations are deriving their data. + +SFC: So the proposal here was to return TRL. Currently, it’s returning RTL. In the pull request, it using TTB, however. TTB is not derivable from the Unicode character database, and from the script Metadata.text file rather. And it also does not clarify whether or not the directionality after the top to bottom is left or right or left to right. Therefore, the—my update would I would like to instead suggest that we approve is to keep this script as RTL, it’s modern and what the text contains. The thing, the actual change, the reason we opened this originally and the thing I think is most important is there is—let’s say there’s an unknown script. Where the implementation does not have data. For example, ZYYY will permanently be in that state. This is the unknown script. And it does not define text directionality. Currently, the specification says, you must return the string RTL or the string RTL. The PR says, you can also return the value undefined. And we should continue to return the value undefined. + +SFC: So what I am proposing in this slide is not exactly what is in the pull request that TG2 has approved, but upon further research and also consulting with Liang \[unintelligible\], we didn’t do our homework, but Liang [?], this is what he said in the issue. The person I can consider to be the closest we have to like a script directionality expert we have consulted with. I can show you his comment on the issue. And this is what he says on the issue. This is on issue 90. I’m sorry, you can’t really see anything in the room. But this is on issue 90. Where he basically says, keeping in left to right, left to right or null or undefined seems to be a design that makes sense. Because other scripts have it more complicated. And because of the complexity of properly modelling discriminate directions it’s reasonable to limit it to be LTR or RTL or unknown, RTL [?] is how he concludes his comments here. + +SFC: Yeah. That’s my latest proposal to TG1. So yeah. Open for comments. + +RPR: So far there’s nothing on the queue. Eemeli? + +EAO: Yeah. Just wondering whether TG1 is the right place to talk about this, which seems like a TG2 topic, to be honest. + +SFC: Okay. So I have a good—I am glad you asked that question. I have an answer for this question. I think that what we shoulding doing here is we should be asking TG1 for approval on making this API which currently only returns a string to be return a string of a shape of a certain shape or undefined because that’s definitely a normative change that we allowed this API to now return undefined instead of a string. + +SFC: Yeah. So I would like to ask TG1 for approval, because this is currently all Intl implementation locale definitely anyway. So asking TG1 to do an appraisal at the API that returns a string can return undefined, I think, is a reasonable conditional approval that the script can do. So we can move forward with the proposal. I should write out what we are actually trying to seek approval on. Alternatively, if we would rather fix up the pull request and come back in July if it’s cleaner to do it that way, that is also fine. + +RPR: Are you going to be writing out something now or will you come back? + +EAO: Yeah. So just to clarify, the bit about the string possibly have the value top to bottom is not at all something to be considered here. So like the text on the screen right now, is not relevant for what is being asked. Yeah. Right? + +SFC: This is the information about what leads to our choices. + +RPR: Nicolo? + +NRO: Yeah. Like, if you original item for discussion on the agenda was like let’s add undefined and let’s also return… Now we discuss the consensus only part of the PR and the other parts of the PR doesn’t get consensus at this meeting and something like approving the undefined change. + +RPR: All right. Shane? + +SFC: Yeah. So I guess the consensus—the thing I am seeking consensus on is one that the—API can return an object with a—with a field containing the string value LTR, RTL or undefined. And then if TG2 feels that the enum should also contain other string variants, TG1 gives this preapproval. Something like this is what I am seeking approval for. + +RPR: Shane has now clarified on the board. + +?: And this is also in the slides which are linked from the agenda. + +?: Okay. Yeah. That is the slides directly. + +?: Okay. So one by one or… ? + +DLM: Yeah. We can go one by one. The first one the API returns a string TLR or the string RTL return the value undefined. And then that’s the first item consensus. The second item for consensus if TG2 wants to add additional string values to the enumeration before reaching stage… + +DLM: I am not comfortable with approval. I would like to come back to TG1. + +SFC: Sorry. You like item 1? + +DLM: Yes. + +RPR: So we had some support for part 1. And I am seeing nods in the room from NRO. Any objections to consensus on part 1? Okay. So I think we have consensus – + +SFC: I will take part 1 and go back to TG2 to see if we need to come back with part 2 later. Part 1 is the most important thing. So thank you for redoing this. + +RPR: Great. And thank you, Shane. Do you want to dictate a conclusion or summary or do you prefer to edit it in the notes? + +### Speaker's Summary of Key Points + +Shane presented an update on the `Intl.Locale` proposal with the focus on the pull request adding number 101, which is adding `undefined` as a return value if the direction is unknown to the gettext info API. + +### Conclusion + +TG1 approves adding the return value of undefined to the return value of gettext info, but the committee would like more time to consider adding other string values to the enumerations. So TG2 will go back and update the pull request with that feedback. + +## Maintaining Proposal Topics + +Presenter: Mikhail Barash (MBH) + +- [slides](https://docs.google.com/presentation/d/1jWTwZ91AbZvS8OYwDzmNdG4CmN20oyBn9qPHd3FmOQI/edit?usp=sharing) + +MBH: Yes. So this is a project that we were doing in TG5. + +MBH: So the question that we asked ourselves is, first of all, what are the trends in the language evolution. And the second question is, what are, if any, the patterns in the stage bumps and stage duration for proposals? + +MBH: So the slides I will show now from the—the TG5 meeting which was held at the end of April. It’s worked on together with a student, Kai Waløen, from the University of Bergen. And the data I will be presenting is based on TC39/proposals repositories and the link here mentions the web app which you could play with to see what we have. But I want to just present the brief summary. + +MBH: So here on the left, we have the stage 4 proposals. And we tried to visualize when they were reaching particular stages. On the right, we have the visualization of the duration in months. How much it takes for a proposal to get from Stage 1 to Stage 4. Again, I am not going into the details of any particular proposal. Here, it’s just the kind of research I am looking into. + +MBH: Here is another visualization. On the left, we see the stages of proposals. On the right, we see a classification of proposals. One possible classification that distinguishes API changes syntactically changes and semantic changes. I will talk in details soon about these three. But again, just to give you an idea of what kind of analysis we are doing in that project. + +MBH: Here we have an average duration per change for Stage 4. So again, we have proposals categorized as API changes, semantic changes, and syntactic changes. And we have some idea of how much time does it take for a proposal which is in that corresponding to take to get from Stage 1 to Stage 4. + +MBH: As you can see, the standard deviation here is quite large. So the—there is not much we can actually get use from this analysis. Another idea that we had after that is to try to look into the classification of proposals based on the topics, on the themes that they are representing. And here, we have some topics listed which were randomly chosen for this presentation from more than 100. We identified and just visualized when—at what points in time were certain proposals, at what points of time certain proposals did get to Stage 4. + +MBH: Again, for now, this still is a project in early stages. Still requires some statistical analysis and essentially for us to be able to draw any statistical conclusions from the data. But again, what I care about is about the type of research. Not about this particular analysis that I am presenting. + +MBH: What we want to propose is to have proposal categories and proposal topics. A category is a change that a proposal introduces. It could be a standard library change, a syntactic change, or a capabilities change. I have here more definitions here: + +- Standard library changes: modifications to the standard library and built-ins and their observable behavior. +- Syntactic change: modifications to the concrete syntax of the language. +- Capabilities change: modifications to the interpretation, evaluation, or observable behavior of existing or new language constructs which for no polyfill can be defined. + +MBH: However in the presentation today, I am rather focussing on the topics. A topic is a conceptual domain that a proposal is related to. Here on the slide you can see examples of topics. Asynchrony, concurrency, performance, regex, realms. + +MBH: What we think is that proposal metadata which is grounded in the structure and concepts of the JavaScript language will help support categorization, discoverability and alignment with related proposals. + +MBH: What we would like to have is a change to the process document that will require specifying a proposal’s topics to get to Stage 1. The committee would maintain a non-exhaustive list of top I objects. And I would like to point out here the word “maintain”. It doesn’t mean that the committee will define the list of allowed topics, so to say. The word “maintain” is of technical nature, it means there will be a file in the TC39 repository and there’s a list of proposal topics extracted from the proposal repositories and the topics will be assigned by the champions. Or the authors of the proposals. + +MBH: I understand that assigning topics can be subjective and controversial. Especially when proposals are at Stage 0 and it’s not clear whether it will even get to Stage 1 or what the solution will be or if the problem space is enough? But even if it is subjective, it seems that assigning topics will still provide an organizational value. It will help to identify related proposals, ongoing discussions, the least will be non exhaustive. So we avoid any rigidity, allow for adaptation of new topics. They can be revised. We hope that topics will improve discoverability and cross-proposal awareness. + +MBH: The second part of this slide, which says that we are requiring specifying a proposal category, which can be either a syntactic change, a capability change or an API change, to get to Stage 2 or 2.7—this is not today. I am not asking about it at this meeting. We still have to work out the categories and the definitions for those. + +MBH: So what I am asking for today is only the first item on this slide. To require specifying a proposal topic to get to Stage 1. + +MBH: And this is a more concrete change in the process document. To get to Stage 1, entrance criteria, one new one, identification of topics that characterize the proposal to support discoverability, alignment with related proposals and areas of the language, as well as statistical analysis of the proposal space. + +MBH: This is how we imagine a proposal topics file will look like. An explanation of what a topic is. Then a table or list of list topics which will be updated based on the data which will be added by the champions of proposals. Extracted from the TC39 proposal repository. + +MBH: To summarize, the list of topics is non-exhaustive—it’s dynamic. And it’s going to be the responsibility of a proposal champion to assign proposal topics. No extra burden for the committee. And again, no ask related to the proposal categories. As of today, we have to get the proposals and definitions. Yeah. I am ready for the queue. + +MBH: Luca? + +LCA: Yeah. This is very helpful. I think it would be useful to sort this both into the topics and the categories. I understand you are not asking me for categories right now. I do have a clarifying question on the categories. You mentioned this capability change category. And the definition here was modifications to the interpretation of evaluation or observable behavior of existing or new language structs for which no polyfill can be defined. What is a polyfill? By runtime by existing overriding globals? Or is this, like, syntactic polyfilling, syntactic transforms? + +MBH: I guess what we meant here is that the change would represent a semantic change, which would require substantial modifications to the engines. But I do—I do see your question, in some cases, there could be a polyfill that still would implement that. But if I could very vaguely formulate here that these are modifications for which no polyfill could be defined. + +LCA: A concrete, two different proposals here the structs proposal, which is probably impossible to polyfill because the point of it is to improve performance. And like you cannot polyfill in that way. Whereas in theory there’s probably \[unintelligible\] `Symbol.enter`. A new feature that is pretty easily polyfill-able through, like, a transpiler of some sort. And with very little performance cost. Maybe it’s good to clarify these two in further duration of this in the future. Thank you. + +MBH: Thank you. + +RPR: JSC has a clarifying question on this same topic + +JSC: I talked with MBH about this earlier. Yeah. Program capabilities weren’t a category and I raised it. Getting the idea from DE. JavaScript should be layered. And he talked about program capabilities being an important feature of some proposals, but not others. I think that—I think LCA’s distinction sounds good to me. Yeah. It’s basically, is there something that is basically impossible to do? Behavior-wise? In the engines today from user space, I like, for instance, a lot of—a lot of stuff from like, having to do with secure JavaScript a lot of that is impossible to polyfill today, I think. Let me—so like, I think, new syntax would not like just in of itself would not be considered a new program capability. It would just have to be—is it something that programs today are able to do or not? So like a new hook into engines roughly not polyfillable in and of itself. Structs? Yeah. So like—yeah. So like that’s all I have. + +USA: Michael? + +MF: So I definitely support this process change proposal. I think that the very low amount of additional work, more than pays for itself for what we get from this. And I am excited for the additional future work on categorization and would love to participate in that. + +USA: JS Choi? + +JSC: I also support this initiative. Whatever it looks like. There are very interesting statistical methods that we could apply further to this to try to characterize, like, what—which proposals are likely in general to progress or not based on, like, their characteristics. Things like multistate modelling, that kind of thing. You could even make them—you can view the TC39 processes and mark up changes. For instance, go through different stages. You could calculate the probability in the next few years what a proposal will advance or not just coarsely, based on various… I just polished a study that did that kind of thing. I am interested in this. We can go to of the [WICG.IO](http://WICG.IO) has has Github Metadata. I think that kind of thing might be, like, a sort of far reaching further goal that could take into account categories and whatever as, like, a guiding item. And yeah. I think this is very exciting. And there’s a lot of possibilities. It’s just an ask from champions, not the over the committee. That’s all. + +RPR: Jacob? + +JSH: Just a quick clarifying question on the definitions of these. There’s a capability change that says, for which no polyfill can be defined. Where can one be defined? + +JSC: I am a little—sorry, if I am not super coherent right here. The way I view it is, yeah. I didn’t write the polyfill definition per se. The way I see it is, whether, like, it does something that programs aren’t capable of doing in user space right now at all. Like behavior-wise, semantic-wise. Like I mentioned earlier, trivially, we could exclusive new syntax in and of itself from the definition. It’s whether, like, you could write user space code that does the same thing. I think that’s—that’s what we could mean by polyfill. Obviously, this is all very stretchy right on and off. But if you have, like, if we want to make this really robust definition, it’s would be great to have you involved in the process. + +JSH: My question is not the definition of a polyfill. But the definition of capabilities changes. Where no polyfill can be defined. I am asking about the case where it otherwise matches the definition of a capabilities change, but a polyfill is possible. + +JSC: Hmm. You have an example in mind where, like, you could write user space with that emulates the same behavior? + +RPR: I think this conflicts with what when no user-land could cope with this, therefore there is no such thing as a polyfill for it. + +JSC: Do you have in mind a user space where it could have the same capability, but wouldn’t count as a polyfill. To me that’s what a polyfill is. Like – + +JSH: One that comes to mind is possible is, the existing pattern matching proposal that could probably be polyfilled in addition to the language. I think it would otherwise fit this definition. + +JSC: Okay. So here we have, like, an extension—standardized extensibility thing. And whether we count that it’s a new program capability. Yeah. So, like, I think that we could bikeshed over this. It’s a grey zone, in my opinion. We probably shouldn’t count it as a “new program compatibility.” Or throw it into a new category like new standardized hook or something. I don’t know. I think this is something to bikeshed. Like, broadly, though, the distinguishing between proposals that bring some kind of new behavior capability—semantic capability to user space, that can already be done versus one that doesn’t is a useful thing. Like, Dan Ehernberg has raised. I think for proposals that one of the big points is that creating a standardized point of coordination of standardized points of coordination could theoretically be done in userland, but now it’s being done in the language itself. Plus their syntax. That could be a useful third category—like, separate binary of variable or it could be—we could stuff it into this. I don’t know. We could bikeshed it. + +RPR: In the interest of time \[inaudible\] go ahead. Waldemar? + +JSH: Yeah. For sure. Just was curious. Thanks. + +WH: Yes. Having seen what happens in various instances of keywording and similar activities—if you leave keywording to a diverse group of people, you’ll get a lot of interpretations of what the keywords mean. Looking at the list of topics earlier in the slides, I would have no idea if a proposal qualifies for \#performance, \#ergonomics, or \#others. This produces a bunch of bad data. + +WH: I would prefer to see a more consistent interpretation of what the topics are and a proposed list of topics. I know you have the one on the slide, but is that what you are proposing or is the list something to be developed later? If it is something to be decided later, then I think we should have a discussion about whether to use it at a time when we can actually see the list of topics. + +MBH: So the list of topics I have shown on the slide is an example of work done by a student. And it would be much better if a proposal champion would actually assign topics to their proposals. As I mentioned here, the list is not to be maintained by the committee. So it would be a task for a champion. Here, it’s just one example of an explanation of what topics could be and I think what we could do is, try to give a list of some topics that are examples. But again, this is not a rigid list that a champion of a proposal will have to follow. + +RPR: Just to check, Waldemar, would it satisfy your concern here if there was a definition associated with each keyword? + +WH: Yes. I would like to see a concrete list of what we are talking about. Right now it’s too vague—too abstract. + +RPR: Okay. + +WH: And I am uncomfortable with simply saying that the proposal champions can put any keywords in there, because that will just create a bit of chaos due to folks naming similar concepts differently. + +RRR: Thank you. + +DJM (on queue): Support requires specifying a proposal’s topics for Stage 1. + +MM (on queue): Please start a repo to start issue threads presumably to discuss this. + +RPR: So interested in discussing further. That’s the end of the queue. Were there any discussions there, that you would like to ask more questions about? + +MBH: A question to WH. What would be the concrete steps that you would like to see? So that this becomes possible. + +WH: I would like to see a list of topics together with definitions. Your current list has \#ergonomics and \#performance, but I don’t know what those mean. You have gone through all the existing proposals and somehow assigned topics to them. So I would like to see a candidate list. + +MBH: Yeah. + +WH: This would make the discussion more concrete. I have nothing against doing this kind of keywording; I think it’s a great idea. But I want us to all be on the same page about what the keywords mean. + +MBH: But then what would happen if a proposal champion defines their own key word for their proposals so they will also have to provide a definition for that + +WH: Yes, you can define new keywords. What I don’t want is to have some proposals tagged with \#performance and others with \#speed. That’s not helpful. + +RPR: Okay. Mark (MM) has a recursive question of what topic and category would you give this, your particular proposal here, Mikhail? + +MBH: \#N/A—Not applicable. + +WH: \#meta + +RPR: All right. That’s probably a sufficient answer. + +JSC: I think we can—there could be a “meta” or “process” or “TC39” topic or category or whatever. + +RPR: That makes sense. MF? + +MF: It seems like we might be able to resolve WH’s concern in the moment, if we can just take a look at the existing work from your student as some examples and that might just clarify the kinds of topics that would get associated with these proposals or we might expect champions would associate with these proposals. Failing that, maybe it would—I would like to ask and it would be sufficient to have, like, a—to use that as starting point with, you know, associated definitions. So can you walk us through—show us some of that + +MBH: All right. So… just to show some examples of proposals with some categories on the right. + +MF: Can you make it bigger? + +MBH: Yeah. + +WH: You guys are talking, but I cannot hear you. + +RPR: Sorry. Waldemar. That’s my fault. + +?: It’s sounding like we have general support, this overall approach with Waldemar asking for this extra piece of information which is a central definition which we can append to as we go. + +WH: Yes. For example, I see a lot of `\#others` in here. And I don’t know what that means. + +MBH: Yeah. The topics that are shown here examples, they are not necessarily supposed to be used. These are just examples. This is a student’s work, where he tried to classify the proposals according to the topics. This is just to demonstrate the idea of it and as I mentioned the exact topics will be defined by the champion because they know the proposal. The definitions of proposal topics are any way to be given by the champion, not by the committee + +RPR: That isn't disputed. The champion will make the selection from the topics. They are asking for the central terminology definition. + +RPR: All right. + +RPR: We are approaching the end of the time box. + +RPR: Mikhail, do you want to—are you asking for some formal approval at this point? Or do you think you have enough to go forward with this? + +MBH: Well, I would like to ask for this modification that is shown on the slide. Perhaps with some conditional approval on having a file with the definitions and an explainer document + +RPR: Okay. So the request here is to add this one new bullet point to the process document, under the condition that we haven’t specified yet, this we will also maintain a central record document with the meaning of each topic that is used. + +MF: I would just like a clarification whether—or when this goes into force. Would it go into force starting now? At the end of the meeting? When? + +RPR: Mikhail? + +MBH: Well, this could come into force starting the next proposal. + +MF: So now? + +MBH: Well, if it’s a conditional approval, it cannot be now because we have to main—to create a document with the explanations and the definitions. So essentially, as long as it’s approved and it’s merged to the process document + +RPR: Effectively this is approval in principle and need to get the mechanics in place before enforcement could start + +MF: Okay. We could approve the process change and when it lands in the process document, that’s when it goes into effect? + +RPR: And we could gate landing on it, having all the mechanics + +MF: That sounds good to me + +RPR: All right. We have got a few questions here. Let’s see if we can get through them quickly. Eemeli + +EAO: The list of initial tags or whatever we call these, be a part of the discussion that was just referenced, be an upcoming discussion? + +MBH: The topics for the champion to choose from—this could be there. Essentially, some examples of topics will be there. We cannot require every champion to go back to their proposal, especially if they are not with the committee anymore, so—yeah. + +RPR: Waldemar? + +WH: I feel like we are trying to go from Stage 0 to Stage 4 in one step here. Somebody will need to come up with a candidate list of topics and present those topics to the committee, so we all know what they are. That would be a good time to try to change the definition of Stage 1 process to require those. And I do think that we should discuss whether proposals currently in flight will need to be keyworded or not. + +RPR: Thank you. SHS +1 + +SHS: Go ahead. + +RPR: SHS says, a lot of mechanics to discuss. CM? + +CM: Yeah. My concern is very, very parallel with Waldemar’s, which is, I think in principle, I think this is something like this is a really good idea. But I think as far as an actual process change, I think that’s a much more invasive kind of impact on the entire work flow of anybody’s counterproposal. It doesn’t feel like this is sufficiently baked in terms—I am hearing confusion, when is this going to take effect, what is the rules, and I think to actually adapt—to say we have consensus of making a process change, I don’t think we have enough of a description of what is a process change actually is. And I think the language is too vague. And when Waldemar said going from Stage 0 to Stage 4 is right. This is a Stage 1 or 2 for the process. And it needs some sort of maturing before I think we adopt it. + +RPR: Thank you. I am asking in the queue \[inaudible\] + +MBH: Thank you, everyone, for the comments. We will keep working on this and hope to come back at one of the next meetings. + +### Summary of Key Points + +This was a conversation about how we as a committee manage tracking, labeling, auditing, and supporting all current staged proposals. TG5 is interested in providing a technology solution for this. + +### Conclusion + +- Interest in principle but further refinement needed. + +## AsyncContext web integration brainstorming + +Presenter: Andreu Botella (ABO) + +- [proposal](https://github.com/tc39/proposal-async-context) +- [slides](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?usp=sharing) + +ABO: So we’ve been trying to figure out what the web integration should be for AsyncContext. We have gone through a number of proposals. This is kind of a brainstorming to see what the next steps should be and so on. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g35b2dca8356_0_0](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g35b2dca8356_0_0)] + +ABO: So here’s the recap. First of all, AsyncContext allows propagating storage that is local to async—so to speak, it is like an async version of thread-local storage. And it would propagate through await. And in the web integration, we were proposing it would propagate through various things. And the main categories are schedulers, such as `setTimeout` and various other APIs that take a callback and run it at other points. The callback would be called in the same context—like with the same local source, or in the same thread in this analogy—that the API is called in. And this is easy to implement through WebIDL. + +ABO: And then we have event listeners and similar APIs, where if an event is fired as a result of JS code in the same origin, it would be called in the context of that JS code. So you do `addEventListener` and pass in a callback. And that callback is run in the context of whatever triggers the event. For APIs that fire an event asynchronously—like, a typical example is `XHR.send()`, that sends a request asynchronously, and eventually triggers the `load` event, `loadstart` and so on. But it is not always straightforward to find every API that can cause an event to be fired asynchronously. That is part of the issue that we were having here. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g3484e1b5507_0_13](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g3484e1b5507_0_13)] + +ABO: So the proposal is currently at stage two. And it is blocked on the web integration and building consensus in WHATWG around it. And Chrome has been engaging a lot due to task propagation, which is something that Chromium has been working on internally. That would be very similar to AsyncContext and could be built on top of it. And they’re supportive. Mozilla has been engaging a bit, and they have a negative position. WebKit has not really been engaging really so far. And they haven’t had a position. So the thing we need to change is Mozilla’s negative position if we want to propose to advance. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g3484e1b5507_0_7](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g3484e1b5507_0_7)] + +ABO: The position Mozilla has is, this is a niche use case, only useful as implementation detail for project libraries. We hopefully addressed this last time—there’s a widespread need for AsyncContext in major front-end frameworks. And that is not only inside those frameworks, but it would help have a simpler API for authors. There’s also developer complexity, and developers don’t always know what context some callback or some code will run in. And yeah, with the update of the web integration proposal and the presentation we did last time, this should be addressed. So now, there’s a consistent context in which the callbacks and events are called. And then the other feedback was implementation cost. Our proposal would affect the implementation of a large number of async APIs that will start an operation that will eventually trigger an event. That will be costly to implement, and we have not been able to address that so far. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g358fa25f941_1_12](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g358fa25f941_1_12)] + +ABO: So we have some kind of tension between addressing developer needs and avoiding complexity in browsers. At least some developers would want the AsyncContext to always be propagated with the code flow—like anything that causes an event or some other code to run would carry the context. And browsers in general would prefer to propagate as little as possible, or, at least to avoid as much work as possible. And we have actually found some cases where the needs for some developers were higher than our previous proposal. This is some feedback from developers at Canva who were asking for propagating the context in which an observation happens. Like if you change a style in the DOM, like a class for example, and that causes relayout for an element, and that causes a ResizeObserver callback. They would want that to have the context in which that DOM element was changed. And our web integration proposal is not specific about this, but this is not something we thought was needed. And some developers do have those use cases. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g358fa25f941_1_39](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g358fa25f941_1_39)] + +ABO: So we’re trying to find the right balance. Yeah. And that is the main topic of this discussion and the main issue. So which factors do we consider? There are multiple things that we can consider for each API and use cases. "How widespread?” It is fine if, if APIs are more niche, they would need more developer caution. “How difficult it is to implement propagation in browsers”. For some APIs, it is trivial. For others it is not. Like, it is different for different APIs, and it can be a factor. And then “how difficult it is to implement in JavaScript without native support”, because libraries could monkeypatch some built-ins and propagate the context, or provide their own wrappers, and only those libraries would be affected if it is not propagated adequately. So libraries can monkeypatch so the users would not notice this is propagated. So we will look at various examples one-by-one. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_0](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_0)] + +ABO: The first one is `await`. This is kind of the core of the effective proposal, the reason this is there. It is basically everywhere. The context that would be propagated is: once that you have an await, you are in a context before the await, and that propagates to the code that runs after it. So when you reach the await—or you do `Promise.then` which would be equivalent—the context gets saved. And as I said, it gets restored on the `then` callback, or after the `await`. + +ABO: This is reasonably simple to implement in engines, we have this already with `ContinuationPreservedEmbedderData` in V8. My understanding is that Bun added this to JSC and it was relatively simple. It is not possible to polyfill this in JS, because `await` doesn’t use the monkeypatched `Promise`, it uses the built-in one. But of course, it could be transpiled. This is what frameworks currently do. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_6](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_6)] + +ABO: There is `setTimeout()` and similar schedulers. These are probably common, and the callback is intuitively a continuation of the code that calls `setTimeout()`. So the context in which the callback is run would be the same context in which `setTimeout()` is called. This is easy to implement in engines because it can be done through a WebIDL attribute—and we will be hearing more about that later on in the meeting. And so, there would be an attribute that associates every callback passed to that API with an `AsyncContext.Snapshot`. You would have one single implementation in the WebIDL codegen that would work with all such schedulers. How easy or hard to polyfill in JS? This is easy to monkeypatch, but we don’t want to end up in a framework with all the monkeypatch timeouts. This happened with React and fetch—if you have different frameworks, the monkeypatches will override each other. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_12](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_12)] + +ABO: And then, `addEventListener`. It is quite common in the web, and covers different events. And obviously different events might have different needs. And what matters here is async events that are dispatched by JavaScript. For synchronous events, like if you called `dispatchEvent` or if you called `.click()` on an HTML element; that fires the event synchronously, immediately in the call. And that would not need any special handling. Just the implementation of AsyncContext would handle that. What we’re dealing with here is async events. + +ABO: In our proposal, our latest one, if an event is fired by JS code that calls into an API, the event will use the context that the API is called in. This is hard to implement in engines because for async events, propagation would need to be implemented separately for event dispatch that was called by JS. + +ABO: And polyfilling this in JS is difficult. And it depends on the events. Apparently, most frameworks have their own event implementation. But for tracing, some events are easier to monkeypatch, such as `XMLHttpRequest`; and others are very difficult or impossible, such as bubbling. And, well, it is true that depending on the type of the event, some people might not think of the actual event listener as a continuation of the code that triggers it. It depends on the event. For `onClick` maybe not, but for `load`, like load on XHR, it tends to be one. So the actual behavior that we end up going with might depend on the event. But in principle here we’re proposing to maybe drop this and, well, this is what we’ll be brainstorming about. + +RPR: Before moving on. Can you go back a slide? I wasn’t going to go to the full queue, but there is a clarifying question. + +CZW: Yeah. I just want to clarify that the “drop” here means that it does nothing extra handling on the `addEventListener`. So it does not mean that `addEventListener` will not observe the changes in the AsyncContext, but it means that it will naturally observe what is in the AsyncContext, like if we dispatch an abort event synchronously, it will just observe the synchronous context, what is available at the synchronous stack. But for asynchronous events like click events, it will just observe the empty context. So it is like the default behavior. So, the “drop” here means that we are not adding extra handling to the events. Thank you. + +ABO: Yeah. It means that the behavior that you would get is just the behavior that there will be if you implemented AsyncContext in the JS engine and did nothing on the web browser. That clarification was definitely needed. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g3361f02a261_0_0](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g3361f02a261_0_0)] + +ABO: {Readable,Writable,Transform}Streams. They have this underlying source/sink/transformer, which is the object that you can pass to the constructor. That has methods which are called when something happens to the stream. So you use this to define your custom streams. And in our current proposal, the `pull` method on the `ReadableStream` underlying source would have the context that causes the current read or write to the stream. How difficult is this to implement in engines? It is not clear, it depends if the browser follows closely the specification, because the specification reads very much in terms of operations on promises and so on. And if that happens, then it would be easy to implement. But like at least in most cases, it wouldn’t. + +ABO: Polyfilling this in JS would be very difficult if not impossible. I must say that in some cases it seems like this might not be the behavior that developers would expect here for the context to propagate. We have heard this from JSL. So I think at least some developers would expect the context to be the same as when you create the `ReadableStream`. So maybe it’s fine to drop this. And developers that need this could just do `AsyncContext.Snapshot` to get the context that they want. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_18](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_18)] + +ABO: Then there’s observers. In the proposal as we had it—well, as we still have it, before the changes that we’re proposing today—observers would have the empty context, but as I mentioned earlier, they have been explicitly mentioned by developers interested in using the proposal to improve their app’s performance. But doing things that might be very hard to trace in engines like V8. `MutationObserver` would be straightforward to implement, I think. `{Resize,Intersection}Observer` would not be, because the context would need to flow through the rendering pipeline and CSS and so on. Like this is what the folks from Canva were asking for. Polyfilling this in JS would be impossible, but the fact that it’s impossible to polyfill in JS is not enough of a justification considering that it would also be very difficult to implement in engines. So here “drop” means it would have the same behavior that we were proposing in the web integration, but we were including this slide because we have heard feedback about it. And it might also need to be part of the discussion. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_24](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_24)] + +ABO: And then we had the idea of the fallback registration-time context. Which was a way to provide a default context, or a default value for variables that are defined in a specific zone of code. This is something that Bloomberg asked for. It is also something that would be useful in the server side when you’re defining a request and you want to track a request ID. Because you don’t want that variable, that state to be lost in an event or something like that. + +ABO: And yeah. This is useful for dependency injection and ownership tracing. So this is not difficult to implement in engines per se, it is just more work. And implementing this in JS is not simple, but it’s possible, and it would be easy to monkeypatch the API in other ways. And if we’re dropping the async propagation for events, this probably doesn’t need to be a part of the web integration. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_49](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_49)] + +ABO: So, yeah. And we’re going to dig a bit more into what “drop support” here actually means. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_55](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_55)] + +ABO: Without any explicit AsyncContext in the web platform, you have the “current async context” as a property of an agent. This is reset every time a scheduled job starts running and it changes when you call an async variable. So for callbacks that are called synchronously, the async context would not change unless the callback is run through `AsyncContext.{Variable,Snapshot}.p.run`. But for anything that happens asynchronously, the context would be lost, and it would run in the root empty context which would have the default value for all `AsyncContext.Variable`s. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_62](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_62)] + +ABO: We were considering having ad-hoc integration for some specific use cases. So, for example, promise rejection—for the `unhandledrejection` event we might want to expose the context that caused the rejection. This would be useful for some use cases that would want to maybe do something like `AbortController` to abort some pending operations on a region of code. So if you have multiple pending promises that you’re racing, or some promise that started at some place and will be awaited at a later point, if something rejects you want to kill all of them. And this would be useful for that. + +ABO: The `onmessage` event, that is part of the `postMessage` API with `MessagePort` and `BroadcastChannel` and so on, is used as a polyfill for other scheduling APIs. It might be interesting to propagate the context here. This is not needed, but it could be good performance-wise. + +ABO: And for other web specs that build on top of AsyncContext that our colleagues that are working on, they could special-case variables to be propagated in special cases where the current AsyncContext doesn’t. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_68](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_68)] + +ABO: So the goal of the discussion is: what can we sacrifice to simplify the web integration? We will bring the result of this brainstorming back to web folks. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g3591e5d9ae5_2_1](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g3591e5d9ae5_2_1)] + +ABO: We also have a discussion next week in the Web Engines Hackfest. This is a breakout session for Wednesday, I believe. This is the issue for that ([https://github.com/igalia/webengineshackfest/issues/64](https://github.com/igalia/webengineshackfest/issues/64)). + +MM: So, when you talk about propagating over `postMessage`, you are talking about propagating between agents. You’re not—so, what would you be propagating? I don’t understand. + +ABO: Yeah. `postMessage` can be used same-engine but cross-realm. Well, some—so the use cases where `postMessage` is used as a polyfill for scheduling APIs, it happens even in the same realm. You just do `window.postMessage`, as in the current window – + +MM: Okay. So, if you’re in the same realm I understand. You don’t have to go on with that. But you know, typically, the reason you’re reaching for `postMessage` is to communicate between agents. + +ABO: Yeah, we should have made this clear. We’re not looking to propagate anything across agents. + +MM: Okay. What about between shadow realms? Do you anticipate propagation across the boundary? + +ABO: So, the async context would be a property of the agent. And you wouldn’t be able to observe the state of an AsyncContext.Variable inside of the shadow realm, but by calling external functions, you would be able to influence, and you could pass data along through there. But it is in context, so ShadowRealm would not have a `postMessage` method. Well, it currently doesn’t. + +MM: Yeah. So suppose the argument is that, between shadow realms, since you can’t have variable shadow realms that exist on both sides of the boundary. You can’t have a binding to the variable object that needs to be observable on both sides of it. So all you need is to propagate the abstract context. And it doesn’t cause any cross-realm connectivity. Is that, am I getting this right? + +ABO: So, if you had, like let’s say that we support `postMessage` inside shadow realms—like, it doesn’t fulfill the criteria for shadow realm, but let’s say that we do. And you expose it to the outside. Then, that context would be available inside of the realm. You wouldn’t observe that it is, you couldn’t observe that it has any of the variables from outside of the realm, because you can’t cross them into the realm. But you could call external functions from outside of the shadow realm with that context and maybe those functions would be able to do something with those AsyncContext.Variables. + +MM: Okay. So the cross-realm call, which, of course, we have, called via a boundary, those cross-realm calls can propagate the abstract context, but each variable is only observable on one side. You can actually use that technique as well over `postMessage` between agents, I think. + +ABO: No, because—the way that you would observe this is, you would call something on the shadow realm and that function would call back outside of the shadow realm with the same context. And you would be able to observe that because the context does round trip, but cross-agent the context does not round trip. + +MM: Okay. I would like to come back to this sometime, but that’s fine. Thanks. + +NRO: Yeah, just, if we have long discussions, let’s maybe then convert questions to topics, or people can add themselves and push discussions to not clarifying questions. + +NRO: Well, MM already understood the answer to whether he was right was yes. + +RPR: And CZW points out that MNY also said `postMessage` is a commonly-used polyfill with the set media API. + +SHS: So, just bouncing off of that, yeah. It is used very commonly for same-realm scheduling, and as someone that tried to polyfill, I don’t think it is possible to polyfill. It is not propagated, it is quite a bit of a problem. + +ABO: It’s very hard to polyfill, especially if you can have other event listeners listening for the message. The way to write a polyfill is storing the context in some map and passing the ID as part of the message and then stripping that out somehow. So that would be the way to polyfill this. But if you have any other listeners, they would not see the right message. And you would need to store the context in the map, which could introduce memory leaks. This could be a recurring thing. + +SHS: You got to know that you’re not passing it outside, which you can’t always tell, I think. + +ABO: Yep. + +NRO: Yes. So I’ve talked a little bit with frameworks, sharing with them the slides before the meeting. And I got feedback from SolidJS, Svelte, and Vue. I didn’t ask React, which is the one using the scheduler trick. But anyway, for the other frameworks, the answer from all of them, from their use cases of figuring out as part of rendering which things are used, all they really care about is the basic stuff. Like the most important is await. One of the framework makers, I think from Solid, even said actually for their specific case, even if we did the proposal without `setTimeout` they would still be very happy. The only negative comment I’ve got about this approach was from Vue. It was not about how people would use this in context for the framework. It was more about like—worried in general that developers might be surprised when the context is lost in some cases. And however, even though frameworks said it is fine to propagate, just remember that there’s not only the framework use case, the use case opposes addresses (?); there is also the tracing use case, where it tries to figure out why something happens in your code across complex or basic (?) scenarios. For those use cases, like the more information you have, the easier it will be to reconstruct what was going on. + +MM: So the whole design space here is very interesting. And from the same sort of abstract design principles you can arrive at the opposite conclusions. So I think the most important one here is principle of least surprise. The first intuition that people come to for this is that the propagation is from some cause into the computation that is the effect triggered by that cause, but what actually happens, of course, and what all of this has done, there are often multiple causes, and for a given cause, there are often multiple effects caused by that. And the second, it doesn’t itself create a problem. But the premise we chose registration context for `postMessage` was suggested here is also registration context. For other things, what’s suggested here is not, it is explicitly the non-registration cause. I think the thing that we need to be most cautious about is to just judge it on an ad hoc basis and say, “well, for this particular effect that has multiple causes, registration seems most intuitive; but for this other one, the non-registration cause seems most intuitive”. And just pick it based on some intuition per case. I think that will just create too much of a memory burden on the programmer and too much surprise. So we need to make these things more predictable. + +[Slide: [https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_62](https://docs.google.com/presentation/d/1yBtSvF5z3P4PliB2NziYzm90d27keiX2P9-MfoDvpJs/edit?slide=id.g359118292c5_0_62)] + +MM: One of the things that’s an interesting concept shown on the slide that is currently up, so I’m glad we’re on this slide, is the `.rejectioncontext` property. That’s actually a very interesting and general way to deal with this ambiguity. When there are multiple causes, just capturing a context with an explanatory name for the property in which you capture it for each of the kinds of causes, and then if there’s an implicit context that is automatically propagated, to just do that which is most uniform with the rest of the language. + +MM: Now, the other way to apply the principle of least surprise, it comes from opposite conclusions, is for each one of these event propagating abstraction mechanisms, what if somebody just wrote that event propagating abstraction mechanism in JavaScript, not paying too much attention to what context gets propagated? Especially for such frameworks that already exist and are going to continue to have their old code distributed on the web before AsyncContext came about: what context do they naturally propagate implicitly? Because users of frameworks are not going to carefully think, “oh, well, since it is a framework I should expect this behavior—or, since it is the browser’s own built-ins, I should expect this other behavior”. This principle of least surprise would always cut towards do what would naturally happen for user code that is unaware of AsyncContext. I don’t have a conclusion from all of that. I just wanted to open up the whole realm of design choices raised by those principles. + +ABO: The web integration proposal that we presented in Tokyo had registration time. Like the registration context for events, you call `addEventListener` or set `onClick`, whatever—the context when you call `addEventListener` is the one that would be active inside of the listener. That is a solution. But Mozilla complained it would introduce memory leaks, because no one ever calls `removeEventListener`. Our newer web integration proposal that we discussed last time, last month, had the dispatch context, which is “for every event that has a JavaScript cause in the same agent, that cause is the one that provides the context”. But this is very hard to implement. And Mozilla also was negative about this because of the complexity and implementation. So both of those options for, for the general case are no-gos. So the only option that we’re left is to not do anything with events, and if there is an async event, not propagate anything except for some very specific needs, because doing the general case in both options with the registration time and the dispatch context is a no-go. So here we’re trying to salvage what we can. + +MM: Does that also argue for or against explicit context captured in properties? On the – + +ABO: Yeah. So properties, it depends. So for sync events, that would be nothing special, like, you wouldn’t need a property. For async events, it would be as hard to expose this as a property as to have that as the context that is exposed on the callback. The only thing, if you have a property on the event, this would be less useful to tracing if they are expecting some context to be propagated through a continuation in user code, and the user would not know that they need to do something with the property of the event. But there is the upshot that properties can be added without breaking web compatibility. Whereas changing the context of an event dispatch isn’t. + +RPR: We spent quite a while on this. I think I would like to move to the clarifying question from SHS. + +SHS: Yeah. So—I think I had a couple about the registration context. I kind of lost the context here, but—I think we haven’t defined dispatch versus registration very well is sort of it. But I think I don’t have anything else to say here. + +RPR: And your follow-up? About exposing snapshots. + +SHS: Yeah, what ABO was saying, for tracing needs you really need to recognize (?) context or the most natural one for tracing to flow implicitly. The fear we have, if application developers are having to manage the context explicitly it will lead to a lot of cargo-culting and just sort of always wrapping some context, rather, and the data will be a lot worse as a result of that. + +LCA: It is actually the same amount of work just setting the context when calling the event here. Particularly if you do not do anything special for event dispatch, like just setting the context prior to actually dispatching the event, because events are dispatched synchronously will just work. For implementation there is no reason to do this through properties, rather than through anything else to deal with this. And like, we will have polyfills that need to overwrite `EventTarget` and it’s—yeah. + +NRO: Yeah, so properties are much simpler to implement from browsers than the implicit one, the reason being that for the implicit one, they must just do it for all of them. While a property can be weighted especially to have the name—like the ones on the screen can be evaluated on a case-by-case basis and propagate the context when it is actually useful or it matters. For us, every specific event is the same complexity, but a much smaller number of events that have the property and also can be done incrementally if needed. + +ABO: And there is also like, use counters cannot really be written for implicit propagation. But if we’re changing the propagation on a property, we could see how many pages are using this particular property. And determine whether we can break context there, where with implicit propagation there would be no way to do that effectively. + +CZW: Yeah. I also want the mention that even though I personally prefer that context can be implicitly propagated for events rather than properties, but when we propagating through properties, the advantage is that we don’t have to spec out every event’s context when we first release AsyncContext. Otherwise, there will be breaking changes for these events. So through properties, we can incrementally add more support for more events without blocking the AsyncContext proposal as a whole. Properties can be added as a nonbreaking change and complementary addition for more events. So, yeah. That’s the advantage of properties versus the implicit context for events. + +LCA: We’re focusing the entire discussion on that one browser vendor said this is too complicated to implement. That is obviously something we have to discuss. But on the other hand, one of the other browser vendors is very much pushing for this and doesn’t think it is too complicated to implement. For users, the property thing is way, way worse than the implicit propagation thing. In the order we should be designing the language, I think users come first, designers come second, and implementers come third. And the spec comes after those. We’re focusing a lot on the latter half on the four things right now and not on the first half, which I think we should be doing. So I think, I also have not heard at all from any of the implementers other than Google here—which, thank you—about the actual concerns and things being discussed. So I would really like the implementers that are actually objecting to these changes to further elaborate what is so complicated about this. I understand some of the parts that are complicated here, but we’re making very large trade-offs here for implementations. And I feel like you should justify yourself for that. + +YSV (on queue): It should be users over developers over implementers, over spec authors. Complexity leads to security and performance issues. Those impact users. + +LCA: One of the other things you mentioned here in the last paragraph some other web specs that build on top of AsyncContext allows them to be propagated. I don’t understand this at all. I feel that is more complexity than all of the variables being propagated. Can you explain this? + +ABO: Yeah. So what we’re discussing in particular is the equivalent of doing `.run` in an implementation of an API for a specific browser-internal variable that would not be more difficult than propagating things for all variables. The thing with, if we do propagate those things—if for those particular events the context would propagate for all variables, that would be an inconsistency, like we have also heard like complaints about having consistent API surfaces, or behavior, and in those cases, which would be easy to propagate, maybe having those event propagate the context and others don’t, like—we might not want to expose that to users because of the inconsistency with other events. + +NRO: Yes. Also, this would be just an implementation detail like browser internals. Like there are other proposals outside of TC39 in web land, such as task attribution, that work in ways that are similar to AsyncContext. So it would be nice if they could be implemented reusing the same mechanism as AsyncContext, such as using the AsyncContext internally. And cases they behave differently, just have special handling for those specific cases. This is not user-exposed. The variables are all internal. From a user point of view, it is completely a regular event, so users would be able to say please propagate the specific variable in this other way. + +CZW: Yeah. There’s another comparison when we spec out the event context on ad hoc basis on a general basis. So, for a general solution, we have to add a spec notation to the web API so we can statically look at the context and test general for each browsers. But for ad hoc events the complexity is much more limited for a specific event and we don’t have to spec out a general notation to say which event should propagate the context from which API. So it is much more simpler implementation-wise and spec-wise, so that’s why I think the complexity here would be more on the general solution basis. + +LCA: So I think one of the things you said, ABO, the inconsistency between different events—some events propagate, some events don’t. Is that something we want? I think that is a fair question to ask. And I think—because of what we have seen so far, especially in the tracing use case, the more the better. It makes sense for things that are easy to propagate—for example, like the `load` events on XHR is really easy to propagate. Implementation-wise, this is simple, it would not add vulnerable securities, or harm users because the slows down performance in any meaningful way. Not doing that because it is inconsistent because events do not propagate through `ResizeObserver` or, I don’t know, CSS animations or something—I don’t think that’s useful. I think we should like consider this on the basis of like if there are a lot of things that are relatively easily to implement, and I think most of the JS API that dispatch events that do not involve the DOM fall into that category. We should just do that. Even if it is inconsistent with asynchronous DOM APIs, where it would be really very difficult to propagate and have high implementation complexity, which I understand. + +ABO: Yeah, so the cases where it would be hard to propagate events asynchronously, the cases we had in mind was not CSS animation, but tricky things like—well, most, most of the ones that I know are related to the DOM. Like, document events where calling `document.close` can fire the window `load` event, which you might expect would not be triggered by JS code. But it can, if you do `document.close`. And it is those kinds of things where there’s a lot of interaction which can eventually trigger an event dispatch. But like, maybe—I mean, I guess not having events related to the DOM propagate the context as you’re saying, it might be fine implementation-wise, but it’s, well, there is the inconsistency and this principle of least surprise that we were talking about. And yeah, is this a design decision that we want to make? That’s also part of the discussion. + +MNY: I think this topic was queued up quite a while ago and I did want to bring up resources like `