igrigorik: hello!
plh: hello:)
plh: I finally managed to setup the automatic bikeshed on w3c/longtasks
Charlie: PRing the {buffered:true} at https://github.com/w3c/performance-timeline/pull/76
spanicker: Concerned about no upper-limit on buffering
cvazac: Planning to cap it at 1000
spanicker: should the buffer cap be part of the spec?
should there be a global buffer cap for all entries?
cvazac: planning to limit only server timing entries to 1000
nicj: should the buffer be limited if we're killing it at onload?
spanicker: would it be cleared at first observer?
cvazac & igrigorik: no, since second observers should have access
cvazac: buffered true eliminates some races conditions vs. getEntriesByType()
igrigorik: proposal to add a new flag to registration that defaults to true. need to read through it
cvazac: we're all good for serverTiming. Need to discuss PerformanceTimeline changes and there are missing hooks
igrigorik: Let's take this to the PR and find the right plumbing
Memory Pressure: https://github.com/spanicker/device-ram
Shubhie: Starting a prototype and working with gmaps and other devs for getting early feedback
igrigorik: should we simplify the levels or add more?
spanicker: A single signal might not be enough, as devs may do different things based on pressure levels
also background and foreground matter as well. They can query visibility state, but adding it to the API can be convenient
igrigorik: is the discussion captured on the public repo?
spanicker: It'll be captured in the doc
igrigorik: we need the latest proposal up to date, so that rniwa can comment
toddreif: So you're prototyping in order to see how devs use it? Concerned that publishers may use this differently than Google/Microsoft properties
spanicker: G properties are not necessarily memory efficient
toddreif: Is mobile the main consumer? We think mostly of desktop
spanicker: Both. A lot of interest from emerging markets. But also desktop oriented interventions
toddreif: So the main question is the number of states?
spanicker: Yeah, but also maybe more prescriptive. Indicating memory pressure + You're in BG
igrigorik: So there's Memory Pressure (temporary state), overall memory (permanent) and "user wants a light experience"
yoav: should "light experience" be converged with the data saving mode? Different UI, but similar delivery mechanism and semantics
spanicker: memory is not the only factor. CPU also plays a major role
spanicker: but maybe better to start with individual signals
igrigorik: take a look at the docs and let's resolve offline.
toddreif: It's very easy to understand and implement memory pressure. amount of RAM may raise privacy concerns
spanicker: rounding will help?
toddreif: Not sure what's the solution, just raising a concern. If Chrome privacy will be happy, MS privacy folks are likely to follow
igrigorik: High resolution time
https://github.com/w3c/hr-time/issues/32
There's an issue with Firefox there
xiaoqian: In Chrome when you open a window you get the document, in Firefox the document returned is an empty document, which breaks the test. Might be a Firefox bug. Need to find a workaround
igrigorik: We may need to talk to annevk to see who's bug it is
Do we move the spec to PR?
toddreif: yes, we should
igrigorik: plh, can you help?
xiaoqian: I can
igrigorik: Performance Timeline
PerformanceObserver support in worker are lacking
spanicker: It looks like a conscious implementation decision
igrigorik: it's not clear why Chrome chose to omit support from workers
plh: doesn't work in Edge
toddreif: PerfObserver is under consideration
spanicker: should we push for perfObserver use?
igrigorik: There are new APIs that rely on it, so good time to push it. Also need to explain difference from buffering
toddreif: Just remember that IE11 will never get PerfObserver, so please caveat
plh: It won't get longtasks either
toddreif: yeah, but when moving older APIs, it requires feature detection
igrigorik: the buffer work cvazac is doing will make it simpler
igrigorik: should we file PR transition to L2?
plh: Would be nice to know the state for workers
igrigorik: we can check Safari implementation status and look at implementing on the Chrome side
yoav: idl files in WebKit indicate Worker exposed
igrigorik: might be enough for PR then
igrigorik: NavigationTiming
igrigorik: comma separated list and several headers should be identical according to HTTP
will take another pass on the PR
toddreif: I'll take a look as well
NavTiming2 is in both Edge and Chrome57, so we can transition to REC
Only issue is in reporting URL in name, which is shipping in 57, and got no compat issues
spanicker: as shipped right now, only available after onload. The next fix is to expose it earlier, which will land in 59
toddreif: will look if usage increased since Chrome shipped. Or maybe not, since it's hard to tell
only small differences: Edge doesn't have secureConnectionStart, Firefox has most of the support for 2 right. So Firefox and Chrome are the 2 implementations
igrigorik: Should it move to CR?
plh: should go along with ResourceTiming. We should move them together
igrigorik: in theory I agree, but will potentially stall the process. RT has many outstanding issues that we need to triage
so can hold NT2 back
toddreif: Are the blocking issues on that version?
igrigorik: not sure, we need to go over list and see which critical and which cosmetic
igrigorik: so let's do that and then decide if we move both or only NT
igrigorik: Page Visibility
Manual prerender test https://github.com/w3c/web-platform-tests/pull/5185#issuecomment-288803532
good to land
toddreif: the test is testing the right behavior, but do we land the feature which is at risk?
toddreif: should work at IE11, but haven't tested yet
Edge has no intent to support prerender
igrigorik: should we land it as it's at risk?
toddreif: we should do that when the feature is required
plh: if you support prerender you should support the prerender visibility state. We should add a note that it might be removed in the future
igrigorik: how is that different from "at risk"?
igrigorik: I suppose that we land the test
plh: sgtm
plh: from a REC point of view, at risk can be removed. A note is just a warning for developers
igrigorik: so you propose we remove the "at risk" and add a note instead and transition that to PR?
plh: Yeah
igrigorik: wfm. Todd?
toddreif: ok by me as well
igrigorik: Next, Beacon
igrigorik: Need to file CR
plh: filed, but not yet approved
if all goes well, we can publish by tomorrow
WPT https://github.com/w3c/web-platform-tests/pull/4024
toddreif: dev that pushed it is the one that implemented the Fetch updates. Will bribe dev to finish this
nicj: was there an update in spec regarding overall beaconed bytes?
igrigorik: updated to 64K in-flight bytes, which matches the Fetch spec
igrigorik: the implementation in Chrome has that limitation, but it'd change when Beacon is reimplemented over Fetch
igrigorik: RequestIdleCallback
should we move to CR?
toddreif: don't block on my review. 2 implementations with Firefox and Chrome
igrigorik: we see good usage, and ready to file PR? Objections?
no objections noted
plh: will try to request the transition this week