Re: WebPerfWG call - July 2nd @ 10am PT / 1pm ET

Minutes
<https://docs.google.com/document/d/e/2PACX-1vTojhGqZTinkuvOgMPxYLggCwg_XXTVbXUql2WdHRuSqQO8HUjr32OxNLkzXao6LqpUwJX1b69SMp_b/pub>
and recording <https://www.youtube.com/watch?v=foSwl-WH4uE> of last week's
call are available.

*NOTE: We are skipping next week's call (Jul 16) for summer recess.  See
everyone back on July 30.*
Participants

Noam Helfman, Yoav Weiss, Nic Jansma, Hamidreza Jahtalabziabari, Michal
Mocny, Michelle Vu, Nicolas Pena, Benjamin De Kosnik, Philippe Le Hegaret,
Steven Bougon, Gilles Dubuc, Thomas Kelly
Next Meeting

July 30th at 10am PST / 1pm EST
Presentations

Page visibility - slides
<https://www.google.com/url?q=https://docs.google.com/presentation/d/100v6-4uHofi0XXhHK2fxLvwxrnUBtampVamsHmdnwq0/edit?usp%3Dsharing&sa=D&ust=1594411051625000&usg=AOvVaw0i6lh8k6LPzx7Xge9bN0w0>

   - Nicolas: Problems - page visibility gives us incomplete history
   - … For paint timing you want to take visibility into account, otherwise
   the timings are tainted
   - … Not super discoverable for Paint Timing
   - … Outcomes for discussion:


   - No need to add API to solve discoverability - RUM vendors and
   performance teams can surface it. Documentation can also help.
   - Need to add a new visibility PerformanceEntry - one for initial state
   and another for each visibility change
   - Could deduce first one from current visibility state and any changes,
   but having the first one in the buffer explicitly is nicer for usability


   -


   - Regarding duration - might be useful/confusing to add duration of
   visibility change handlers


   - Nic: Feel like duration of handlers would be useful but having it be
   another explicit attribute (processingStart) would be clearer
   - … Duration of 0 would be fine, since other entries like Marks have a
   duration of 0
   - Noam: For the first event, would it make sense to insert it
   artificially?
   - Nicolas: Yes the first state would be inserted with startTime=0
   - Yoav: If a page was loaded and never moved to background or
   foreground, how would you know what state it’s in?
   - Nicolas: You would query the current visibility state
   - Yoav: So at the moment you’re querying you have to look at both the
   current visibility state and the buffer
   - Nicolas: Yeah and that feels a little sketchy to have to do that
   - Nic: Would be easier to use if we always emit the first entry
   - Noam: Any other indicator that the entry is the first one?
   - Nicolas: The startTime would be set to 0
   - Nicolas: Another comment on PageVisibility was that it is not really
   performance so why is it PerformanceObserver? Answer is that it’s the exact
   buffering we need and it helps Performance analytics. Alternatively we can
   reimplement PO as an independent thing
   - Noam: Makes sense to reuse PO
   - Yoav: Same here
   - Nicolas: Bikeshedding the name: VisibilityState? VisibilityStateEntry?
   - Nic/Noam: PerformanceVisibilityState? VisibilityStateEntry?
   - Benjamin: Goal is to keep consistency - VisibilityState seems
   acceptable
   - Michelle: If we passed the buffered flag, does that give the entire
   history?
   - Nicolas: Yes, but it will only buffer until it becomes full. But
   buffers should be large enough so you can assume you have all the history
   when your register
   - Michelle: So initial entries may be dropped
   - Nicolas: No, it’s the last ones that can drop
   - Michelle: Interested in seeing the first ones where people toggle, as
   a sort of abandonment
   - Nicolas: So need to look at the second entry
   - Nic: Proposal regarding reasonable buffer size?
   - Nicolas: Didn’t gather data yet. The number is probably not huge
   - Nic: When you call the buffered flag, you don’t know if the buffer was
   reached. Edge case, but might be useful.
   - Nicolas: Valid point. Can add a flag to the observer callback
   - Nic: Is currently not known and can change over time, so would be good
   to export it. I’ll open an issue
   - Nicolas: My next steps are to send PRs to page visibility, as we’d
   probably define it there.
   - … Also, Page Visibility defines VisibilityState already, so probably
   don’t want to override it
   - Michal: Whether or not we add initial visibility entry: if we did not,
   and the suggestion is to infer the initial state from any changed states,
   right now that works because there’s only two states (visible and hidden).
   If another state was added (e.g. we had prerender), you couldn’t infer the
   first state.  So it’s good to be explicit.
   - Yoav: Should be an L3 thing, because L2 is almost done
   - Plh: Cool with that
   - Yoav: Maybe worthwhile to try to wrap up L2

TPAC

   - Nic: Getting ready for TPAC. Virtual meeting this year.
   - Yoav: One thing we need to decide is what week we want to meet
   - … Official week is Oct26 for unconference sessions
   - … The week for this working group’s TPAC meetings should not be that
   week.
   - … There’s a form with 3 questions:
   - … (1) What week we can have this TPAC
   - … (2) We were talking about having hackathon days before TPAC (which
   we did at previous meetings).  We’d have a few online sessions to attack
   multiple issues.  Somewhere in August or September.
   - PLH: TPAC will be free this year
   - Yoav: (3) Final question is what timezone works best, we’ll try to
   make it as less awkward as possible
   - … 4x 3-hour meetings in a single week over 4 days
   - PLH: With a break in between the 3 hours
   - Benjamin: One meeting a day is preferred
   - Nic: Ahead of time we’ll be doing some prepwork with agenda so people
   can join for topics they want to discuss

Process 2020

   - PLH: Started review of Process 2020


   - … Will be effective in September 15
   - Yoav: If we wanted to adopt the patent policy, we need to recharter

Reporting API Question

   - Noam: Error reporting API to support crashes
   - Nic: You do get crash reports today
   - Noam: Anything beyond crashes?
   - Nic: There’s a discussion around that. Was recently split into
   separate specs. Discussion on additional data, but it can be privacy
   sensitive
   - Noam: Useful to understand the source of the crash
   - Yoav: OOM crashes are split apart, for other things crashes are a
   source of privacy and security issues so we don’t want to send those
   reports to arbitrary sites
   - ... If it’s a render crash, some browsers may have cross-origin
   information in those renders, which isn’t OK for one site to share
   - Nic: Today the only available reason is OOM

Element Timing API

   - Noam: Currently it supports img, svg, etc. Would it make sense to add
   support for canvas?
   - … We’d need to define what it means - every draw to canvas? The
   initial paint?
   - … I initially thought we’d want it to reflect the first time the
   canvas is painted.
   - … Most of the expensive drawing is done off screen, and it would be
   good to measure when the canvas is shown to the user
   - Nicolas: Makes sense. If the canvas is built off-screen, wouldn’t you
   know when you placed it, when it comes on screen?
   - Noam: You can always have an onload handler, or register a
   requestAnimationFrame?  But not as accurate.
   - Nicolas: Could you file an issue?
   - Yoav: Are any paint operations asynchronous?
   - Noam: API is sync but operations may be grouped and executed
   asynchronous
   - ...: Only once a script completes drawing, not for every operation

Abandonment API

   - Nicolas: Wanted to clarify that Origin Policy is not coming soon
   necessarily. Does anyone have thoughts on the path forward for abandonment
   API without Origin Policy?
   - … The options seem to be:


   -  to use something like NEL without under-specified caching.
   - Make current Origin Policy work for us, but that won’t work for other
   use-cases of Origin Policy


   - … Thoughts?
   - Nic: Don’t know much about NEL caching. Is it not well specified?
   - Nicolas: It just says that the UA will cache as it wants
   - … are there any other issues with NEL’s mechanisms?
   - Yoav: Chrome security folks are concerned about arbitrary headers
   applying to site-wide things
   - … They consider origin policy to be a more centralized way for how an
   origin should behave
   - … But no one currently owns it
   - Nicolas: What are the concerns?
   - Yoav: A single resource that defines policy for origin-wide things,
   isn’t healthy
   - Nicolas: COnclusion is we have no idea yet how to register for
   Aborts/Abandonment



On Tue, Jun 30, 2020 at 12:39 PM Nic Jansma <nic@nicj.net> wrote:

> Hi everyone!
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>
> for our next call (July 2nd @ 10am PT / 1pm ET) we aim to have discussions
> on:
>
>    - Page Visibility feedback - Nicolás Peña
>    - Spec hackathon?
>    - TPAC prep
>
> If you have any additional items you'd like to discuss, please add to the
> agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>
> .
>
> Join us <https://meet.google.com/agz-fbji-spp>!
>
> The meeting will be recorded and published online afterwards.
>
> See you soon!
>
> - Nic Jansma
> @nicj
>
>