Yea, I agree that it's a bit weird. What we want is to report longtasks to browsing contexts sharing the same renderer process (is this equivalent to sharing the same event loop, or can there be more than one event loop per renderer process?). Is there a concept for this in the spec we may use?

A browsing context can encompass multiple processes so perhaps using them at all is a problem here?

Ok, so we can change it to use the docs that are defined in the Update the rendering step.

@plehegar mentions we may want to also figure out if other specs are affected by this same discrepancy

Well, this is the only specification that update the rendering invokes with browsing contexts, right?

@plehegar - could you clarify your comment from the last call?

Re-adding the requires-discussion label since I think we need to agree on the scope on which longtasks are reported. Right now, if If A nests B and B has a longtask then it may be reported in A when they share a process, regardless of origen (sure, implementation detail, but I think that's the current state).

That sounds very bad and indeed a bug.

It's not obvious it's bad, although it's bad that it wasn't discussed. Performance APIs are most useful when they measure all the things that affect you, and for long tasks, I think that would be everything in the same thread at least. (Which reduces to same process if we're ignoring tasks in workers, which I think this API does.)

But, we're currently moving toward restricting these sorts of process-wide APIs behind COOP+COEP. I'm not sure what attack exactly would be possible by detecting cross-site long tasks though...

I imagine this was discussed at some point before this API was shipped. @spanicker can you provide some context? Oh I found this relevant document but not clear to me who it was shared with outside of Google at the time. https://docs.google.com/document/d/1tIMI1gau_q6X5EBnjDNiFS5NWV9cpYJ5KKA7xPd3VB8/edit