Participants
Nic Jansma, Yoav Weiss, Peter Perlepes, Noam Helfman, Steven Bougon, Nicolás Peña Moreno, Michal Mocny, Carine Bournez, Alex Christensen, Annie Sullivan, Benjamin de Kosnik
Next Call: November 5th @ 10am PST / 1pm EST
Minutes
- Add attendance and proposals/ideas/use-cases to the doc
- Yoav: Spec says timestamp resolution should be at minimum 5 microseconds (but not less than that)
- ... In practice, many UAs have coarsened resolution due to Spectre/Meltdown
- ... We would like the spec to allow for different values of resolution for different scenarios
- ... As a result of Spectre/Meltdown we now have the concept of isolated contexts
- ... Which allows us to enable various powerful features such as Shared ArrayBuffers, JS Self Profiling, Memory Measurement
- ... Want spec to say it's OK to be higher resolution than 5us in some contexts
- ... This PR is to change that
- ... Wanted to discuss value for non-isolated contexts, as different browsers do different things
- ... Don't expect all browsers to align
- ... Hoping to align on a minimum for non-isolated contexts
- Michal: You're saying there is a new proposal for isolated contexts, but do we want to change the existing 5μs threshold too?
- Yoav: Suggesting we move non-isolated guideline to be higher than 5μs
- ... Proposal to keep it at 5μs in isolated contexts, 100μs in non-isolated contexts, with some UAs allowed to keep higher values than that
- Ben: Agreed as a minimum
- Yoav: Right now if I remember correctly, Firefox is limited to 1ms. Is this something Firefox would consider lowering to 100μs?
- Ben: In the PR, we share our direction, in favor of establishing a floor but not a specific value
- Yoav: Alex?
- Alex: Our long term plans involve site isolation, but until those happen, we are not willing to lower our minimum.
- Yoav: You're OK with minimum in the spec being 100μs for non-isolated contexts?
- Alex: Lower resolution than 5μs would allow you to see other system activity
- Nicolás: Can you review your values for isolated and non-isolated
- Yoav: For isolated, 5μs. For non-isolated, 100μs.
- Michal: The current processing model uses SHOULD and RECOMMENDS, are you proposing a change to MUST be?
- Yoav: Processing allows for providing coarser resolution than the minimum, implementation can provide higher values than that
- Nicolás: Current spec says 5μs for both cases. This proposal is, for non-isolated contexts, we are increasing the minimum granularity value from 5μs to 100μs
- Ben: Is this the last HRTime issue?
- Yoav: There is an open issue to be better integrated with the DOM spec, where they want access to the raw times for internal purposes
- ... Because L2 is already in REC, we kicked off a L3 editor draft that we can link to
- ... Hoping to turn that in a living standard with a new process and charter
- visibilitychange:hidden doesn't fire during page navigations
- WebKit bug 151234 – visibilitychange:hidden doesn't fire during page navigations
- Michal: Philip filed the issue RE inconsistencies between browsers
- … Safari fixed visibilityChange on navigation
- … Double checked the status, versus original table from a year ago and browsers improved
- … Chrome on Desktop, closing a tab or browser does fire a visibility change
- … Chrome on Android - the app switcher is firing, but the test is buggy (localStorage issue maybe)
- … Remaining difference on Safari - tab switcher or app switcher doesn’t fire the visibilityChange event
- … Video continues to play
- Yoav: Tested and on Android device, video continues to play as well
- Michal: Firing hidden may change behavior
- … May need a third state here? Safari may be likely to keep this “visible” to prevent breakage
- Npm: What’s the use case of a third state?
- Michal: Clue that it’s no longer interactive, no longer usable, cue to send analytics, but since it’s not hidden, you shouldn’t disable animations or pause video
- Ben: How are we describing this in HTML?
- Michal: Not very well specified ATM
- Npm: If we fire it when you close the tab from the app switcher, would that be a problem?
- Michal: Tab switcher would work but the app switcher may not give you enough time to fire the events. Today on Android, Firefox and Chrome, AppSwitcher fired hidden immediately.
- Npm: But video is still playing from the app switcher
- Michal: Yeah, and it’s a feature. We're assuming it's hidden but not really hidden.
- … Maybe the easiest solution to the problem is to still fire visibility hidden when the app is killed. But more likely to miss opportunities to send beacons.
- Npm: The main concern is having a way to reliably use the visibility change to beacon performance data. No particularly strong use case to having a third state, but would be ok with it for a reliable callback
- Phil: Developers may not be checking for “hidden”, but for "not visible”. Is that what you’re suggesting?
- Michal: Yeah, webkit folks didn’t want to change to hidden
- Phil: I don't disagree, but it's a concern taht most of the code on the web checks if "visibility state is hidden", so adding a new state would not help
- Yoav: Seems like we'd have an incompatibility issue if we went with a third state, undesired breakage by tab switcher or may no longer beacon their data when it's in effect
- Michal: Existing browsers that change to beacon will break beacons, but we can not ship the new state at first, and only webkit will do that.
- … The whole point is that there used to be a tri-state (prerender)
- Npm: Seems worse to have one browser behave differently, using a different state name. Need to investigate sending hidden in those cases
- Michal: On Android, both Firefox and Chrome send visibility change the moment you launch tab switcher, but killing the browser fast enough may not enable beacons.
- … We can’t change to that strategy and hope to be as effective. But we can try.
- … Safari also dispatches unload correctly, so maybe we should first fire visbility change first
- Phil: Was related to bfcache, where Safari wouldn’t fire unload if the page is BFCache eligible, same direction Chrome is going with its BFCache implementation
- Ben: Can we outline the acceptable solution space? Tri-state?
- Alex: I haven’t followed this, so not the right person. Tri-state doesn’t seem a great idea.
- Ben: Can we get a quick overview of the last attempt to use tri-state?
- Michal: Third state was around preloading, put it in anticipation of use but wasn't
- Yoav: Prerendering was the third state, when we would prerender on desktop, but that changed to link rel=prerender as a hint to prefetch resources but not actually render the page.
- ... Discussion about Prerender flag's history, how it may be potentially revived in Chrome under different criteria
- Michal: Quad-state would make the disadvantage of tri-state negligible
- Yoav: Assuming sites actually take all of those states into account. We need to maybe gather some data on that front, if we can move from two state to something else
- Nic: Is that something we can easily check usage of in HAR
- Michal: Look for equals vs. non-equals? And it depends on the context, are you looking for that or the opposite
- Yoav: I think both equals and not-equals, they're not semantically different. We need people to do if/else on visible/hidden.
- ... Hidden and "preview" share some characteristics that we may want to maintain, and visible and "preview" also share some characteristics
- ... Add a use-counter for visibility events, and inspect ~100 sites to see what would break. Seems painful, but the only way to do that analysis.
- ... Or run an experiment to see if people complain, bugs surface, etc.
- Nic: With all this, what are the best next steps? More data on usage? Talk to Ryosuke?
- Yoav: I don't think it's just an iOS thing.
- ... If some videos stop when going into tab switcher and others don't, maybe we already have a compatibility problem
- Michal: If any web app is nice with turning off animation and videos, they may not realize
- Yoav: Think we need to do more research here, see if there's already breakage in the wild
- Benjamin: Thanks Michal for the useful discussion. Interested in hearing more about prerendering at TPAC
- Nic: Content in iframes could be shifting and affect the visual user experience
- ... the spec suggests that iframes contribute to their parent CLS scores
- ... Proportion as a size of its viewport
- ... In practice it’s hard to measure this consistently with RUM
- ... Synthetic tools and RUM don’t account for that. (e.g. Lighthouse)
- ... My concern is that we need to be consistent with those measurement in RUM
- ... Similar to other issues with iframes, resources/long tasks, where in order to get those events you need to register perfobservers on those iframes - crawl the tree, etc
- ... Also, iframes could be created dynamically and deleted, so the picture would be missing
- ... And cross origin iframes make things even harder
- ... If we can’t easily measure layout shifts in iframes from RUM, we’d diverge from synthetic once they fix up
- ... Bubbles flag proposal would help.
- ... Second proposal, to opt-in for a cross-origin iframes would also help to get info from 3Ps.
- ... We talked about those solutions - not super controversial, but not as much clear use cases beyond ResourceTimnig data. Layout shifts is yet another use case
- ... Should we continue this discussion?
- Noam: Clarification question - CLS is based on the portion of the iframe in its embedder, how is that calculated?
- Nic: Subframe weighting factor, aka pixel weight
- Noam: iframe may be partially hidden, and the layout shift may shift the iframe itself. So it can change its weight
- Nic: Talking about layout shifts inside the iframe, not in the parent document
- Noam: Yeah, but the shift only needs to count if the shift is itself visible. So need to be weighted based on the iframe’s visible area. But layout shift changes may change the weight of other iframes.
- Npm: Subframe weighting factor is computed on every frame on the visible part of the frame, it can change per-frame
- Noam: Defined in the spec?
- Nic: *quotes the spec*
- Npm: CLS is non-normative, as it’s not explicitly exposed. Needs the portion of the iframe that intersects with the viewport to compute the CLS.
- ... Can add a usage example where a frame computes its score.
- ... But there’s no canonical way to get the score from your iframes.
- Nic: “bubbles” would enable iframes to surface their layout shifts, and maybe also their viewport weight
- ... Any way of getting these entries is currently a challenge
- Benjamin: PerfObservers for every iframe makes this more of a challenge
- Nic: Currently don’t use PerfObservers in iframes for RT for Boomerang, because of their transient nature, so hard to get a complete picture
- Michal: Problem with iframes in iframes - is CLS a factor of its parent, or the ancestor?
- Benjamin: Question from mozilla - would bubbling change the buffer sizes?
- Npm: For the buffering, from an implementation standpoint, you could pass the existing entries from the other iframes. So would not increase the things you need to store. But would require a hop to store those.
- Yoav: Would that require copying entries? Entries would be part of that frame, and also copied to another process
- Npm: Would incur a cost if they are used, but not if they are not used
- Nic: bubbling is not the same as cross origin opt-in, and there are two separate proposals.
- Npm: If you have use cases, concerns, ideas, etc - please chime in