Admin

Next design call: Wednesday 14th, 11AM PST

User Timing L3

FPWD L3 published: https://w3c.github.io/user-timing/

Nicolás: on last call we resolved to do a poll to confirm measure API design

Yoav: the twitter poll is showing 70% for measure vs measureWithOptions

… given that the group was leaning this direction as well, the proposal is to override measure()

… what is the implementation status?

Nicolás: OK, resolved: we’ll use measure().

Nicolás: other then measure() we have everything wired up, behind the flag

Todd: what’s the plan for shipping this?

Nicolás: L3 FPWD is published, I don’t believe any of the outstanding issues are blocking for us (Chrome) to ship L3 or would cause issues down the road

AI: Nicolás to update and resolve measure issue

AI: Nicolás to review other open (10) issues

Resource Timing

Status of RT L2 tests

Yoav: there are some issues with our WPTs

… we still have 7 different tests that are passing in only one implementation

… it also seems like it’s the same underlying issues for some (~3) of them

… can we get folks on Firefox / Safari side to get 2 passing implementations

Todd: the goal here is to either have a bug with intent to fix, or explicit feedback objecting

… that would be sufficient for us

Markus: we have a new person on FF side looking into these failures

… I hope we’ll have feedback soon

Yoav: fyi, we’re hitting flakiness bugs on WPT bots for FF nightly

… Ryosuke, could we file issues for the non-passing tests?

Ryosuke: unfortunately we don’t have anyone looking at these

… these are not high-priority compat issues, at least to our knowledge

Todd: let’s make sure that FF engineers review and agree on the proposed behaviors

… this will unblock us from shipping L2 CR

Yoav: FYI, I’ve also found some edge cases in the spec that I’ve added tests for, which may add some new failures; working on landing them, some are pending review from Firefox side; most of these tests are requests from Anne

Markus: ty for wiring up those test from our feedback!

NavigationTiming

Unload event TAO check should be for all redirects #95

Yoav: correct wording should be that only if all redirects pass TAO that this should be exposed

… we agreed on this on last call and I wrote a spec update + tests for it, need folks to review

https://github.com/w3c/navigation-timing/pull/103 - ptal

supported entry types needs to be context aware #102

Charles: the navigation entry type should not be exposed for Workers

Yoav: this doesn’t seem contentions

Nicolás: we fixed this in Chrome, agree that we should update the spec

Yoav: this may not be a NT specific issues?

Nicolás: right, for example worker may not expose longtasks, etc..

… probably a performance timeline issue, that might require an update in NT

Yoav: is this an L2 blocker?

Charles/Nicolás: no

Yoav: marking as L3

Todd: as written the spec would lead you to expect that it should be exposed in Worker

Nicolás: I think we can update the NT spec with a monkey patch, it’s a minor issue that shouldn’t block L2

Yoav: OK, I’ll change it back to L2 and will note that this should not block on Perf Timeline

workerStart should be clearly defined as applicable to the last SW #100

Yoav: in a navigation it’s possible for multiple SW to be involved

… we should clarify that the time reflects the last one

… we can define it in a handwavy way today, and then rebase against Fetch for L3

… proposal to mark it as L2 and do as described

[no objections]

workerStart should be gated on timing-allow check #99

Yoav: definitely an L2 blocker

Should navigationEntry's navigationType be updated according to the parent page? #85

Yoav: definitions for this exist in Fetch and HTML

… but I don’t think we can define better processing until we do Fetch integration

… I think this something we can/should do in L3

Todd: agreed, we need to create more tests, etc.

[resolved, mark L3]

should unloaded iframes be included in their parent document's unload duration? #83

Yoav: we discussed this ~year ago, don’t think we’ve made progress

… we need to write the tests to see if there is existing agreement on the behavior

Todd: agree, this is a less significant issue than previous issue

… if we’re move previous issue to L3 then same here

Yoav: sgtm

[resolved, marking L3]

https://wpt.fyi/results/navigation-timing?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned&q=navigation-timing

Yoav: Safari has a lot of red, guessing due to lack of PerformanceObserver

Markus: we’re looking into these as well.

AI: Yoav and Charles will triage outstanding L2 issues

PerformanceTimeline L2 republishing

https://github.com/w3c/performance-timeline/milestone/2 

Nicolás: I believe above are the only two outstanding issues. Looking at WPT.fyi..

https://wpt.fyi/results/performance-timeline?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned&q=performance-timeline

Charles: failing po-observe tests should go away due to removal of buffered flag?

Nicolás: there may be other failures there

… how do we republish?

Yoav: create an L2 branch off the current gh-pages

… revert or force push to point that we want

Nicolás: which point do we want to point to?

Yoav: can we just manually remove it?

Todd: we want to keep supported entryTypes

... just remove the buffered flag.

Nicolás: ok, that works

… fyi, some tests will be failing to align with the new entryTypes

Todd: yep, as long as you can note which tests need attention

Yoav: I’ll open an issue for “transition to CR”, where we can note tests, etc.