Nic: we’ve been triaging issues, and put things in the “needs WG discussion” bucket. Let’s discuss them
Nic: talked about it in the past, but it’s been a while
Jose: we’ve discussed how to change the propagation in container timing
… If the tree is open, we have propagation rules for that, and only expose the parent element
… We need more time to verify and specify how this interacts with Element timing
… For Element Timing, I don’t see a clear path how how it should be exposed
Jase: We tried to take this into account with container timing, where we have a shadow mode. With it, if you have paint events inside of the open tree you get the events in the parent, but the information is about the shadow root and not inside the shadow tree
… With Element Timing, we still need to spend some time on this.
Nic: Is this something that you want to spend time on at TPAC?
Jase: I think so. We’s like to have a single solution for both specs, so worthwhile to discuss more.
Jose: List of things we should discuss in lengthier session. Also, nesting propagation. Ideas on unifying the attributes and simplifying them a bit.
Jase: I’d love to hear more opinions on this issue
Michal: I think that a closed root should be thought of as a single element. But it would be nice to see the timing data for the root.
… For inside the shadow root, you could observe the leaf nodes inside the shadow root. In Container timing you get a stream of events instead of a single one for the container. For a shadow boundary, you want to summarize what happened inside the tree.
… If any container observes timing, it can ignore.
… But if you import component you can’t know what they were.
… But at the same time, it’s closed for a reason
Yoav: You're saying it's exposed inside Shadow DOM but not outside of it
... Will Shadow DOM have its own Performance Timeline, with registered observers? It's not a different document
Michal: Data is more about where the attribution goes by name. It's not a privacy thing, more a convenience thing.
... If there are two containers, the nested container gets the metadata. PerformanceTimline is not hidden.
... Data inside we have a solution for
... Privacy is different
Yoav: I don't think there's a need for privacy
... We have multiple customers of this data, they need different nodes
Michal: There's another issue where you provide attributes on DOM element itself, and register observers globally
... Another option could have been element.timing where you have no reference to element unless you're inside component
... Register observer scoped to it
... Or provide a MutationObserver-like scope to Observer
NoamH: how would this work with a multiple nested web component: root that has a nested children at multiple levels. Would it all propagate to the top-level root?
Yoav: Will it all propagate to the top level root or will it stop along the way?
Michal: With caveats, there is no solution for this right now. One PO for whole PT. It would provide an entry w/ name and details.
... ContainerTiming feature. Above Shadow DOM you'd "smush layers", one box. You wouldn't know there was a text node and image node, you'd just know the specific component had an update. That would bubble up, in case of nested components. Would look like just a black box.
NoamH: In open model?
Michal: You could be fully transparent
Jase: For ElementTiming, how would this work?
... Open would just work as normal I guess?
Michal: Open question if in the future there's ElementTiming difference, the specs may be merged
Jase: If that's the case and direction we're going, I'm more than happy to work with you and Jose on really having this work of ContainerTiming in scenarios we talked about and work from there. Rather than thinking of solutions separately.
Jose: We don't have usage statistics for the two right now in Chrome
... Could be good input if we're doing a new spec, or both
... We already have users, would be interesting to know
Nic: let’s talk at TPAC
Jose: May need more than 30 minutes
Jase: An hour would be good
Yoav: I think we need more people actively measuring web components, but we need more feedback. I can bring in Shopify people, get them involved.
Noam: Lit framework built on web components, maybe they would care about this?
Yoav: I can try to do that
Jase: Open issue for how Container Timing deals w/ Shadow DOM. If you could add to issue, it would give us some good data for how to sketch out things
Chengzhong: wanted to discuss this proposal again. Last time was 2 years ago and things changed, so wanted to update and talk about the web integration parts.
…
… two setTimeouts being schedules. The second one scheduled would be triggered first, but we’d be able to know that with async context.
… AsyncContext can preserve the value just for a single async task
… The primary use case is for userland tracing (e.g. OpenTelemetry), so that it can trace across async/await operations
… Also useful for soft navigation metrics, and for framework APIs. Interest from React and Solid
…
… The namespace is preserved across async tasks and has a value storage
… A snapshot allows the userland task scheduler to say that save the current task and then restore it later on, to keep the context
… Changes since 2023 - split to two different classes, as they target different audiences (libraries that trace context vs. frameworks that schedule tasks).
… Stage 2 at TC39. Seeking web integration input as we’re preparing for stage 2.7/3
… The proposal needs to work with web APIs that schedule tasks, so that theyd propagate context correctly
… Question: what APIs need to trace context? What APIs can be built on top of this tracing?
… Been looking into setTimeout, fetch, stream readers
… Also: events and performance observers can be split on use cases
… For uses in web APIs: exposing initiator context in resource timing, task attribution, scheduler.yield (as it can preserve context across async/await) which can help preserve the context/signal
… Also AbortSignal/TaskSignal proposals
… How would integration look like? Web APIs that are based on Promises get this for free
… Web APIs that are event driven need specific integration, and we need to see how we should preserve the context across events
… E.g. events that are triggered around system I/O
… In some cases there’s no meaningful context for these events
… For each event, we need to know what their context should be.
… Have an analysis document (TODO: link)
…
… Integration with PerformanceObserver, to enable context to e.g. resource timing and initiators. Otherwise, it may be useful to know the context of DOM changes as part of e.g. ContainerTiming.
Guohui: You mentioned RT and initiator context. Can you elaborate?
Chengzhong: userland instrumentation libraries want to know who fetched a resource. E.g. library that instruments the fetch API and tries to get that in user land.
… For each resource timing entry, there’s only information about start time. We can’t associate it with a particular JS call. Currently developers needs to compare timestamps and URLs, which is tricky/expensive/messy
Yoav: The feature you're working on in terms of initiator, in ResourceTiming, will enable developers to attribute a resource to a certain JavaScript that e.g. potentially imports another script.
... But maybe a single script resource initiated multiple contexts, different resources were loaded, this is something developers would like to keep track on. An extension on the work on embedder dependency tree attribution. Be able to split things up in a single JS.
Guohui: There are many different ways to dispatch tasks. Covers most common ways, e.g. setTimeout() or a Promise. If for example, a script A does setTimeout(), but can be in a different script, that fetches something, it will say the initiator is A.
Chengzhong: Initiator here is referring to context where JS AP like fetch() is being invoked, so I think there's nothing relevant about initiator scripts. For userland JS library, they don't trace the scripts, they trace across the async tasks. Chain of tasks. e.g. chain of async function calls.
Guohui: What is useful is the script data contains the fetch()
Yoav: If a single script bundles together 10 scripts, bundled for perf reasons, developer may want to keep different contexts for those different scripts. So they can blame dependency A vs. B for things getting slow.
... Those are the use cases we talk about that can go beyond the current initiator, if the developer has opted to splitting it up more
Chengzhong: Ultimate goal is similar, for a chain of async tasks, to find which resource loading is the slowest one and takes the most time
Guohui: When people talk about URLs, what script is responsible for this fetch, but there's also the code that does the fetch. Point to the code in the library, but not who called that. Task attribution has multiple uses/purposes. Async variable propagation may be different depending on the data and use case. The challenge is how different use cases, we may want to propagate data differently.
Chengzhong: Do we have a list of conditions where it's propagated differently?
Scott: My goal is to do the same thing. Want to support both.
... Possible APIs would want to do something different, but they could set the var in a different spot.
... You may need to bind registration to a specific variable and set it
... Difference between what we're propagating and setting variable
... Recently refactored code for propagation vs. set variable
Guohui: For initiator URL, it looks similar, who is the caller? Option is to propagate across the async call or not.
Yoav: Another thing we need to determine, in context of Perf Observers, whether we want registration semantics or caller semantics
... Need to determine in order to properly propagate. If it's an opinion developers should chime in on.
... Main call for action is to look at documents, analysis, and rediscuss at TPAC.
Andreu: Biggest blocker is Mozilla is concerned for memory leaks. If the context is registration based, that would mean you'd store the context snapshot along w/ registration and would never be freed.
... We're moving towards the approach for events, dispatch driven, the thing that causes the event is what propagates. If you're in control of code in userland, or of browser, patch event listeners, you can do other things.
Yoav: Sympathize of memory concerns but I think we should prioritize use cases
Andreu: Changing things after the fact could be hard, because of web compat
