Participants

Noam Helfman, Yoav Weiss, Nic Jansma, Hamidreza Jahtalabziabari, Michal Mocny, Michelle Vu, Nicolás Peña, 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

• Nicolás: 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?
• Nicolás: 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?
• Nicolás: 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
• Nicolás: 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?
• Nicolás: The startTime would be set to 0
• Nicolás: 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
• Nicolás: 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?
• Nicolás: 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
• Nicolás: No, it’s the last ones that can drop
• Michelle: Interested in seeing the first ones where people toggle, as a sort of abandonment
• Nicolás: So need to look at the second entry
• Nic: Proposal regarding reasonable buffer size?
• Nicolás: 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.
• Nicolás: 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
• Nicolás: 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
• Nicolás: 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.
• Nicolás: 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

• Nicolás: 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?
• Nicolás: 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
• Nicolás: What are the concerns?
• Yoav: A single resource that defines policy for origin-wide things, isn’t healthy
• Nicolás: COnclusion is we have no idea yet how to register for Aborts/Abandonment