Participants

Peter Perlepes, Yoav Weiss, Nic Jansma, Nicolás Peña, Michal Mocny, Gilles Dubuc, Steven Bougon, Philippe Le Hegaret, Michelle Vu, Benjamin De Kosnik,

Next Meeting

April 23rd - 10am PST

Issues

Long Tasks

• Top-level browsing context scoping

• Nic: Unclear why we’re using a top-level browsing context rather than the document. Is there more discussion to be had?
• Nicolás: Not sure. Probably just an update required
• Plh: We have similar issues in other specifications, so probably need to change it across the board. If I’ll find others I’ll link them
• Nic: I’ll add a note into Github to look at other ones
• Nicolás: The issue is that we want to report Long Tasks to all the browsing contexts that share a process.  I think that’s what Chrome does now.
• Yoav: Should we define it relative to agents and agent clusters?
• Yoav: All documents that share an event loop belong to an agent cluster (and sharing the same process)
• Plh: Is this in the HTML spec?
• Nicolás: In ECMA spec
• Nicolás: The question - should we report long tasks to different documents in the same process?
• Nicolás: If you have multiple top level browsing contexts in the same agent cluster, is it OK to report long tasks from one to another?
• Yoav: So the top-level context in a same-origin iframe would share it, where cross-origin frame wouldn’t.
• Nicolás: Correct
• Yoav: For architectures that have cross-origin documents in the same process, we don’t want to expose right?  I think the answer is yes
• Nic: The Long Task itself?
• Nicolás: The other concern is that a browsing context can have multiple processes, so we should maybe change that to a document
• Plh: An OS process?
• Nicolás: Yes
• Yoav: During navigation a browsing context can hold past and future document
• Nicolás: Should we report every task to every document in the event loop, or should we avoid reporting tasks to some documents?
• Nic: Has there been outside security and privacy concerns?
• Nicolás: If we’re changing it, want to know if people have concerns.
• Ben: I would like to see this clarified. How is reporting multiple processes useful?
• Nicolás: More like reporting all LTs in the process. If we have 2 origins in the same process, all LTs are reported to both. When there are concerns about the origin of the LT, it’s declared “unknown”.
• Ben: Multiple origins in a single process, would the reports be restricted to a single origin with CORS?
• Nicolás: Not with CORS. There are isolated contexts
• Yoav: Concrete example: google.com and Google Docs if they’re sharing the same process, if a LT happens in one it is reported to both, since they can affect each other.  We might not be doing this on Android.
• Nic: Question, does this only happen if one is embedding the other?  Or can it happen if there are two tabs open.
• Yoav: As long as they’re sharing the same process they would both get notified since one can affect the other.  That’s the current way the spec defines it.
• Yoav: Maybe we want to define this in terms of isolated contexts.
• Ben: Where are isolated contexts defined?
• Yoav: It’s another proposal, with COOP, COEP, CORP.  These all enable us to have browsing context that can upload anything either cross-origin or cross-site.  A context cannot load anything that is not explicitly opting-out to being embedded.  For example, then we can enabled shared array buffers or other powerful features that otherwise are scary in the context of cross-origin.  Should we layer Long Tasks on top of those contexts?
• Philippe: Right now TAO is not linked to Long Tasks, would it make sense to use it to gate sharing here?
• Nicolás: TAO is already used heavily so we would probably not want to add it to Long Tasks
• Yoav: If we want an opt-in, isolated contexts is a better opt-in
• Nicolás: I’d like to go with same proposal to change references from “browsing contexts” to “documents”
• Yoav: Proposal to open a new issue to look at sharing within process and how it would work with site isolation

• Event loop timing reporting seems to ignore reentrancy

• Nicolás: Reentrancy is complicated: if a task wants to do some work, it can pause the task, and later restart it.  The time would be inflated.  From my perspective, that’s a bug in the HTML spec and it should be defined as separate tasks
• Nic: Anne’s example was of a sync XHR.
• Nicolás: They probably “cheat” and do sync XHR asynchronously
• Ben: Is this about JS alert()s?
• Nicolás: I’m not sure I understand the use case. Is it because the work after alert is considered in the same task?
• Ben: Yes
• Nicolás: That is a problem… so your task length would be inflated if you have an alert.
• Yoav: Might be good to discriminate against alerts
• Nicolás: If the work is blocked and the process cannot respond to user input, then it’s reasonable to just count it as part of the task length.
• Ben: That seems reasonable. That’s what I’d expect.
• Nicolás: So we can close the issue!
• Nic: Thinking towards attribution, should we somehow flag such tasks? And alert and sync XHR are slightly different there.  Same issue with prompt()
• Yoav: In Terms of attribution, blocking user input gadgets are different from sync XHRs
• Nicolás: My proposal is to wait until we have the JS sampling profiler and solve use cases and attribution like that, as the alert would be in the call stack.
• Ben: I like that
• Yoav: Maybe open issues to remind us that alerts and sync XHR would require special attribution

• Combination of Paint Timing and long tasks can expose precise Paint Timing

• Nic: Ryosuke not here, should we wait?
• Nic: Moved between repos
• Nicolás: Chrome doesn’t surface update-the-rendering LTs. I’m not sure we should expose update-the-rendering LTs at all (should be part of Frame Timing). Removing them would solve this issue.
• Yoav: Makes sense if we don’t currently implement it, to remove it
• Yoav: Should rendering LTs be here versus Frame Timing API?  Removing that from this spec would resolve this issue.
• Yoav: Not sure if Frame Timing would be affected by same concern, but in there we could mitigate it by fuzzing the timing a bit
• Ben: Rational from moving from Frame Timing to Long Tasks initially?
• Nicolás: Possible misunderstanding thinking it was just a Long Tasks problem before.
• Yoav: Paint Timing as specified exposes a start time for the update-the-render step, and rendering Long Tasks (as specified but not implemented) would expose the end time of that step, which would give a precise time of the render.  If we exposed that time as part of frame timing, we could mitigate by fuzzing etc.
• Nicolás: Similar to how we mitigate rAF timing
• Yoav: Another way to mitigate this would be to remove the start point of these tasks.
• Nicolás: Need Ryosuke for discussion on moving the start point. For now we can remove them, and maybe add them later if we’re actually intending to implement.

PaintTiming

• surprising (if not understandable) results for first-paint when `document.visibilityState === 'hidden'` - bool flag in PerformanceEntry or PageVisibility ‘buffered flag’?

• Nicolás: Whether or not to fire FCP if page was hidden at any part
• Nicolás: Prefer a more holistic solution that doesn’t require making paint timing special.
• Nicolás: Options are: Page Visibility (requires some work), but could see the whole history of vis.
• Nicolás: Another option is a boolean flag on the entry that says whether the page was backgrounded before it was created
• Nic: As an analytics provider, the visibility state is a good indicator if we should include the data in our buckets. We had proposals to expose if a metric was affected by the visibility state. Seems preferable to me. Could highlight to the data consumer what the data represents.
• Yoav: Maybe browsers could indicate if the metric was affected
• Nicolás: Prefers something more concrete. In user-timing, do you care about visibility
• Yoav: Depends if throttling happens or not
• Nic: Having information about the page’s full lifecycle when it comes to visibility would be good.  Alternative proposal instead of a boolean on each Performance Entry.
• Gilles: That does take additional work to consume.  Do we need a boolean on the window saying “was this backgrounded”?
• Nicolás: The boolean won’t always work because perf entries can be async or buffered?
• Gilles: Still don’t think that a flag on every entry is the right way to go
• Ben: Strongly agree, just use visibility
• Yoav: Visibility is currently supported (but may be buggy), but we heard feedback from Facebook for example, because in some cases page is not visible before page runs and turns into visible, but cannot tell those cases start.  A boolean wouldn’t be sufficient.
• Nicolás: That’s what I meant with buffered flag for page visibility
• Nicolás: Devs would need to go through the timeline and intersect, but it would provide additional use-cases
• Gilles: The question is: what else could we use it for?
• Nic: The boolean in question is “has this ever been hidden?” or “this entry fired while it was hidden”? If it’s the former, the boolean can get weird after e.g. 20 minutes of running. A log of state transitions could be more flexible for those cases
• Nicolás: SPA apps can observe visibility that way, compared to a boolean entry. User timing & SPAs.
• Nicolás: How to move forward?
• Nic: Are there concerns with Page Visibility, are there concerns in exposing it?
• Nicolás: Already exposed (from event handler)
• Nic: Let’s pick up that discussion next time. Try to solicit more feedback
• Nicolás: post on public-webperf?
• Nic: Yup