W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2019

Re: WebPerf WG triage call - March 29th!! @ 11am PT

From: Yoav Weiss <yoav@yoav.ws>
Date: Mon, 1 Apr 2019 08:13:07 +0200
Message-ID: <CACj=BEitjZWt9oDuXqTZsREo2k+V0=qtGTeZFF1KdkgyrvcABA@mail.gmail.com>
To: public-web-perf <public-web-perf@w3.org>
Minutes from Friday's call can now be found here
<https://docs.google.com/document/d/e/2PACX-1vQO1FpPgpoGZUPaZQDqVLN63ojVAoEQvUxfyyaWl96kipw9GwQ27f1Op4EQk8bPWb0KXJ4tp1iC8xOl/pub>

Copying them to the list for safe keeping:

WebPerfWG meeting minutes - March 29th 2019

Gilles Dubuc, Ilya Grigorik, Tim Dresser, Nicolas Pena, Laurent Dang, Nic
Jansma, Philip Walton, Ryosuke Niwa, Sanjay Hegde, Steven Bougon, Will
Hawkins, Yoav Weiss
Administrativa

   - Next design call: April 12th @ 11AM PST
   - Interest in F2F?


   - Interest in ~mid May, tentatively week of May 13th?


   - Ryosuke won’t be able to attend on 13th but Alex might be able to.


   - AI: Yoav will send out proposal to the group: dates, agenda, etc.

Performance TimelineWebIDL spec does not allow required dictionary argument
with no required members
<https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/119&sa=D&ust=1554102654830000>

   - Make observe() parameter an optional dictionary
   <https://www.google.com/url?q=https://github.com/w3c/performance-timeline/pull/120&sa=D&ust=1554102654830000>


Nicolas: 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
<https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/117&sa=D&ust=1554102654831000>

   - supportedEntryTypes: cache the FrozenArray
   <https://www.google.com/url?q=https://github.com/w3c/performance-timeline/pull/118&sa=D&ust=1554102654832000>

Nicolas: 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]

Nicolas: 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, Nicolas to review PR.
supported entry types needs to be context aware
<https://www.google.com/url?q=https://github.com/w3c/performance-timeline/pull/121&sa=D&ust=1554102654834000>


Nicolas: above issue should address this one as well

Yoav: Charlie opened a PR that conflicts with Nicolas’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
<https://www.google.com/url?q=https://wpt.fyi/results/performance-timeline?label%3Dmaster%26product%3Dchrome%255Bexperimental%255D%26product%3Dedge%26product%3Dfirefox%255Bexperimental%255D%26product%3Dsafari%255Bexperimental%255D%26aligned&sa=D&ust=1554102654836000>),
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

   - 6 non-triaged issues
   <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues?utf8%3D%25E2%259C%2593%26q%3Dis%253Aissue%2Bis%253Aopen%2Bno%253Amilestone&sa=D&ust=1554102654837000>
   - Test status
   <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/71%23issuecomment-462167655&sa=D&ust=1554102654838000>
    - wpt.fyi
   <https://www.google.com/url?q=https://wpt.fyi/results/resource-timing?label%3Dmaster%26product%3Dchrome%255Bexperimental%255D%26product%3Dedge%26product%3Dfirefox%255Bexperimental%255D%26product%3Dsafari%255Bexperimental%255D%26aligned&sa=D&ust=1554102654838000>
   - Pending test - Test XO redirection sandwich with and without TAO
   <https://www.google.com/url?q=https://github.com/web-platform-tests/wpt/pull/13518&sa=D&ust=1554102654838000>

Access to the Remote Address information
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/180&sa=D&ust=1554102654839000>

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
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/190&sa=D&ust=1554102654839000>

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
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/200&sa=D&ust=1554102654840000>


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

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

Nicolas: 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
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/201&sa=D&ust=1554102654841000>


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
<https://www.google.com/url?q=https://github.com/web-platform-tests/wpt/pull/13518&sa=D&ust=1554102654842000>

Yoav: we need to review and land

Nicolas: will review
Navigation TimingNeed tests for…

   - workerStart should be clearly defined as applicable to the last SW
   <https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/100&sa=D&ust=1554102654843000>
   - workerStart should be gated on timing-allow check
   <https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/99&sa=D&ust=1554102654844000>

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
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/104&sa=D&ust=1554102654844000>

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

Nicolas: 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
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/102&sa=D&ust=1554102654845000>

Yoav: should be trivial once perf timeline update lands
secureConnectionStart definition is inconsistent with ResourceTiming
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/84&sa=D&ust=1554102654846000>

Yoav: minor wording update


On Thu, Mar 28, 2019 at 1:58 PM Yoav Weiss <yoav@yoav.ws> wrote:

> I am ofcourse horribly wrong and the meeting is on *Friday March 29th*
>
> On Thu, Mar 28, 2019 at 10:42 AM Yoav Weiss <yoav@yoav.ws> wrote:
>
>> Hey all!
>>
>> Let's solve some issues!! As discussed, this week the call would on
>> Friday March 28th. The tentative agenda
>> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.yo5h5e71az08> is
>> currently:
>>
>>    -
>>
>>    Process improvements
>>    -
>>
>>    Performance Timeline
>>    -
>>
>>       WebIDL spec does not allow required dictionary argument with no
>>       required members
>>       <https://github.com/w3c/performance-timeline/issues/119>
>>       -
>>
>>       supportedEntryTypes API has some issues
>>       <https://github.com/w3c/performance-timeline/issues/117>
>>       -
>>
>>          supportedEntryTypes: cache the FrozenArray
>>          <https://github.com/w3c/performance-timeline/pull/118>
>>          -
>>
>>    Resource Timing
>>    -
>>
>>       4 non-triaged issues
>>       <https://github.com/w3c/resource-timing/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+no%3Amilestone>
>>       -
>>
>>       Test status
>>       <https://github.com/w3c/resource-timing/issues/71#issuecomment-462167655>
>>       - wpt.fyi
>>       <https://wpt.fyi/results/resource-timing?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned>
>>       -
>>
>>       Pending test - Test XO redirection sandwich with and without TAO
>>       <https://github.com/web-platform-tests/wpt/pull/13518>
>>       -
>>
>>    Navigation Timing
>>    -
>>
>>       Applying "timing allow check" to a document makes no sense
>>       <https://github.com/w3c/navigation-timing/issues/104>
>>       -
>>
>>       supported entry types needs to be context aware
>>       <https://github.com/w3c/navigation-timing/issues/102>
>>       -
>>
>>       workerStart should be clearly defined as applicable to the last SW
>>       <https://github.com/w3c/navigation-timing/issues/100>
>>       -
>>
>>       workerStart should be gated on timing-allow check
>>       <https://github.com/w3c/navigation-timing/issues/99>
>>       -
>>
>>       secureConnectionStart definition is inconsistent with
>>       ResourceTiming <https://github.com/w3c/navigation-timing/issues/84>
>>
>>
>>
>> Feel free to add more issues you feel need to be discussed to that list.
>> The hangout link for this meeting is the usual one
>> <https://meet.google.com/nog-ttdz-myg?hs=122>.
>>
>> See y'all tomorrow :)
>> Yoav
>>
>
Received on Monday, 1 April 2019 06:13:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 1 April 2019 06:13:50 UTC