Gilles Dubuc, Ilya Grigorik, Tim Dresser, Nicolás Peña, Laurent Dang, Nic Jansma, Philip Walton, Ryosuke Niwa, Sanjay Hegde, Steven Bougon, Will Hawkins, Yoav Weiss

Administrativa

Performance Timeline

WebIDL spec does not allow required dictionary argument with no required members

Nicolás: this change should only affect the IDL, Chrome implementation already behaves correctly. The IDL harness tests will automatically update when we update IDL.

Will: ty for quick turnaround on this.

[everyone in agreement on proposed behavior]

supportedEntryTypes API has some issues

Nicolás: the intent is to cache per environment. Need to address Boris’s feedback

Yoav: sg, will review the PR.

Will: ty for quick turnaround on this.

Ryosuke: why do we mention cache? Isn’t this just [sameobject]

Nicolás: we want the semantics of [sameobject]

Ryosuke: in spec, we should just say ~“same object returned by the interface”

… “cached” is an implementation detail

AI: Yoav, Ryosuke, Nicolás to review PR.

supported entry types needs to be context aware 

Nicolás: above issue should address this one as well

Yoav: Charlie opened a PR that conflicts with Nicolás’s PR, we need to figure out the path forward, especially if your PR is adderssing it.

AI: Yoav to review Charlies PR.

Yoav: once we resolve the above issues, we can republish L2

… in terms of tests (wpt.fyi), Will landed fixes in FF but looks they haven’t landed

… should be green soon

Will: there is one outstanding red test on performance.mark but that’s UT L3

… there is a timeout issue, but we can square that away

Yoav: can we republish L2 perf timeline CR

[agreement]

AI: Yoav will kick off republish request

Resource Timing

Access to the Remote Address information

Yoav: Feature request, needs security review

Ryosuke: I don’t believe there is any existing mechanism to get this information

Yoav: marking as L3 feature request

Expose JavaScript code caching information in PerformanceResourceTiming

Yoav: similarly, marking as feature request for L3

Ryosuke: commented on the issue, our implementation is very different, not sure if it makes sense for us

Be a bit more explicit about which subresources are to be ignored from stylesheets 

Ryosuke: the whole point of opaque resource is that we should hide the fetches

… cross-origin fetching same-origin should probably be hidden?

Nicolás: currently we only test whether cross-origin resource is exposed, we don’t test this explicit test

Yoav: ~“CSS opaque resource should not expose its subresource”

Ilya: normative change + new test?

Yoav / Ryosuke: normative, need test, and L2 blocker

Specify TAO check for 304 responses 

Ilya: how do other headers behave for 304’s?

Yoav: we should check what CORS is doing

… for now, we won’t treat it as blocker

Ryosuke: based on my read of Fetch, it sounds like we restore headers from original...

AI: investigate current implementation and specs (CORS in particular)

Pending test - Test XO redirection sandwich with and without TAO

Yoav: we need to review and land

Nicolás: will review

Navigation Timing

Need tests for…

Yoav: we need to add some spec wording to make it clear that TAO governs workerStart

Applying "timing allow check" to a document makes no sense

Yoav: we refactored RT to operate on request, not document

Nicolás: a document may not have a request, in which case we trivially pass the test

Yoav: marking as L2 blocker

supported entry types needs to be context aware

Yoav: should be trivial once perf timeline update lands

secureConnectionStart definition is inconsistent with ResourceTiming

Yoav: minor wording update