Re: WebPerfWG call - April 9th 10am PT / 1pm ET

and recording <> from last week's call are now

Copy of minutes:

WebPerfWG call - April 9 2020

Peter Perlepes, Yoav Weiss, Nic Jansma, Nicolas Pena, Michal Mocny, Gilles
Dubuc, Steven Bougon, Philippe Le Hegaret, Michelle Vu, Benjamin De Kosnik,
Next Meeting

April 23rd - 10am PST
IssuesLong 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?
   - Nicolas: 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
   - Nicolas: 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
   - 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?
   - Nicolas: In ECMA spec
   - Nicolas: The question - should we report long tasks to different
   documents in the same process?
   - Nicolas: 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.
   - Nicolas: 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?
   - Nicolas: 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?
   - Nicolas: Yes
   - Yoav: During navigation a browsing context can hold past and future
   - Nicolas: 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?
   - Nicolas: 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?
   - Nicolas: 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?
   - Nicolas: Not with CORS. There are isolated contexts
   - Yoav: Concrete example: 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
   - Philippe: Right now TAO is not linked to Long Tasks, would it make
   sense to use it to gate sharing here?
   - Nicolas: 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
   - Nicolas: 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

   - Nicolas: 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.
   - Nicolas: They probably “cheat” and do sync XHR asynchronously
   - Ben: Is this about JS alert()s?
   - Nicolas: I’m not sure I understand the use case. Is it because the
   work after alert is considered in the same task?
   - Ben: Yes
   - Nicolas: That is a problem… so your task length would be inflated if
   you have an alert.
   - Yoav: Might be good to discriminate against alerts
   - Nicolas: 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.
   - Nicolas: 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
   - Yoav: In Terms of attribution, blocking user input gadgets are
   different from sync XHRs
   - Nicolas: 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

   - Nic: Ryosuke not here, should we wait?
   - Nic: Moved between repos
   - Nicolas: 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?
   - Nicolas: 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.
   - Nicolas: Similar to how we mitigate rAF timing
   - Yoav: Another way to mitigate this would be to remove the start point
   of these tasks.
   - Nicolas: 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.


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

   - Nicolas: Whether or not to fire FCP if page was hidden at any part
   - Nicolas: Prefer a more holistic solution that doesn’t require making
   paint timing special.
   - Nicolas: Options are: Page Visibility (requires some work), but could
   see the whole history of vis.
   - Nicolas: 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
   - Nicolas: 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”?
   - Nicolas: 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.
   - Nicolas: That’s what I meant with buffered flag for page visibility
   - Nicolas: 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
   - Nicolas: SPA apps can observe visibility that way, compared to a
   boolean entry. User timing & SPAs.
   - Nicolas: How to move forward?
   - Nic: Are there concerns with Page Visibility, are there concerns in
   exposing it?
   - Nicolas: Already exposed (from event handler)
   - Nic: Let’s pick up that discussion next time. Try to solicit more
   - Nicolas: post on public-webperf?
   - Nic: Yup

On Mon, Apr 6, 2020 at 8:39 AM Nic Jansma <> wrote:

> Hi everyone!
> Join us <> this week to talk about
> Long Tasks and requestIdleCallback.
> On the agenda
> <>,
> we have:
>    -
>    Long Tasks
>    - Top-level browsing context scoping
>       <>
>       - Event loop timing reporting seems to ignore reentrancy
>       <>
>       - Combination of paint timing and long tasks can expose precise
>       paint timing <>
>    - requestIdleCallback
>       - timeRemaining() step 4 should define what it means to have a
>       "time-critical task pending
>       <>
>       - 6.2. invoke idle callbacks algorithm step 1 should be defined in
>       terms of task sources having tasks enqueued
>       <>
>       - The order of idle callbacks across windows is inconsistent
>       between spec & UAs
>       <>
> If you have any additional items you'd like to discuss, please add to the
> agenda
> <>
> .
> If we get though those, we may venture into ServerTiming issues.
> The meeting will be recorded and published online afterwards.
> See you soon!
> - Nic Jansma
> @nicj

Received on Tuesday, 14 April 2020 12:27:08 UTC