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

Re: WG triage call - April 22nd @ 9am PST

From: Yoav Weiss <yoav@yoav.ws>
Date: Tue, 23 Apr 2019 21:43:15 +0200
Message-ID: <CACj=BEgD=jqxqxooVmVMJVURh=EsGOnuLo8Yw=j=OhQ87LZ1zA@mail.gmail.com>
To: public-web-perf <public-web-perf@w3.org>
Minutes from the call are now available:
https://docs.google.com/document/d/e/2PACX-1vQUJHxJRB8Vy2yv77OvDu7zKHOKKerkYLo0gjThMt2SWijTxd4JNQPnA8FKV52Uc_zADP_o-LUSGguD/pub

Copying them here for safe keeping:

WebPerfWG meeting minutes - April 23rd 2019
PeopleParticipants

Benjamin De Kosnik, Steven Bougon, Tim Dresser, Nicolás Peña, Thomas Kelly,
Gilles Dubuc, Todd Reifsteck, Ryosuke Niwa, Will Hawkins, Philippe Le
Hegaret
Chair

Yoav Weiss
Scribe

Todd Reifsteck

Next call

May 2nd, 10 am PST

Resource Timing:
Specify TAO check for 304 responses

https://github.com/w3c/resource-timing/issues/201
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/201&sa=D&ust=1556052020663000>

Yoav: Discussed on last call and decided to align with CORS. Anne Van
Kesteren said that RFC 7234 defined that cache TAO headers should if the
304 response does not have one.

Ryosuke: What about the other 3XX Response headers?

Yoav: They are different, as they are redirects.

Ryosuke: Should we review all 3XX for proper behavior?

Yoav: The spec doesn’t require updates for these as they don’t require
special behavior. The PR change to fix this is just a note.

Ryosuke: Does the redirection handling match fetch?

Yoav: Not perfectly.. If CORS crosses origins then goes back to
same-origin, it requires the same-origin domain to give access to itself.
TAO does not yet have this. Discussed adding to L3.

Ryosuke: Might be risky to keep it as is, sites may start to rely on
current behavior.

Yoav: It has been this way for awhile, and current implementations are not
all compliant, so risk is low. I’d love L2 to reflect what’s implemented.

Rniwa: If implementations need to align anyway, might as well go with the
end goal spec.

Yoav: That logic relies on Fetch integration, would be easier to do after
integration happened.

Todd: Seems like Ryosuke is saying this leaves a potential privacy leak in
browsers if we don’t write this down in a spec.

Ryosuke: Yes, also risky for compat if sites rely on this. And don’t want
implementers to implement the incorrect version.

Nicolás: Who hasn’t implemented?

Ryosuke: Talking about bug fixes to current tests.

Yoav: Safari/Firefox fail these tests. Chrome passes them. Doesn’t cause a
privacy leak. This intent of making this update is to be consistent with
CORS.

Todd: Why is it specified if there’s no privacy risk?

Yoav: The current definition does protect against privacy issues. The
CORS-aligned behavior does not. There are no privacy risks I’m aware of
that will be blocked by the origin opting-into itself in those cases.

Todd: So we’re just doing that to align with CORS?

Yoav: Yes. We want to be consistent, and want to be able to say TAO is a
subset on CORS.

Ryosuke: It is risky to leave in the current state. It would be ideal if
the spec/tests are updates now.

Yoav: What’s the risk.

Ryosuke: Sites will rely on it and stop getting entries once we change.
It’s better to be more restrictive sooner.

Nicolás: How hard is it to add change to code/spec?

Yoav: Will Safari and Firefox align?

Ryosuke: Once we fix the tests, might as well fix to the right behavior

Todd: If Chrome has the right behavior and Safari or Firefox intend to
align, Is that enough to push to CR?

Philippe: Yes. Maybe even PR, as this is an edge case.

Yoav: Will, are you willing to update the TAO behavior to be CORS-like?

Will: No immediate reason to push back, but need to review offline.

Yoav: Seems reasonable. Also, found an earlier commit that specifies this.
Will make the updates.

AI: Yoav to update spec and tests.

Resource Timing and range requests

https://github.com/w3c/resource-timing/issues/205
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/205&sa=D&ust=1556052020666000>

Yoav: Image lazy loading are likely to trigger more of these. Proposal is
to dupe it to issue https://github.com/w3c/resource-timing/issues/21
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/21&sa=D&ust=1556052020667000>
for
multi-request fetches

Ryosuke: agreed

Add tests for not-same-site nested contexts

https://github.com/w3c/resource-timing/issues/204
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/204&sa=D&ust=1556052020667000>

Yoav: Nothing major to discuss. We need to add tests

Test Status

https://github.com/w3c/resource-timing/issues/71
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/71&sa=D&ust=1556052020668000>

Yoav: Firefox/Safari said they will review tests and give back bugs on
blocking issues. Any progress?

Ryosuke: No updates.

Will: First time I’m seeing this list.

Nicolás: Can we remove the ones that pass in two implementations?

Yoav: This list already precludes those. Can we agree that the tests are
testing the right things and open implementation issues?

Will: Is the blocker for L2 the agreement on the tests, or the alignment of
the implementation?

Yoav: Agreement will enable to move to CR. Maybe PR as well. Philippe?

Philippe: Depends if they are corner cases or not. Major bugs will need
implementation fixes as well to move to PR.

Yoav: So tests are potentially blocking moving beyond CR.

Will: Is the agreement that the tests are testing what they are supposed to
or that the product will be fixed?

Todd: Just following up with regard to timing for Firefox/Apple.

Will: Unsure on time commitment for test review. Maybe > 4 weeks

Ryosuke: Can’t commit any time due to other priorities (WebComponents F2F,
then WWDC). Hope to work on this, but not sure when.

High Resolution Time:
can performance.now() timers be frozen for background tabs, etc?

https://github.com/w3c/hr-time/issues/65
<https://www.google.com/url?q=https://github.com/w3c/hr-time/issues/65&sa=D&ust=1556052020670000>

Yoav: Chrome is freezing performance.now() when tabs are backgrounded. Is
this a Chrome bug? I believe it is

Ryosuke: How does it work? Time is advancing slower?

Yoav: Either incrementing slower or not at all

Ryosuke:Sounds like a bug

Tim: Devil’s advocate. If we don’t pause performance.now, it causes time
between 2 separate performance.now to look like a very long period of time.

Yoav: But it DID take a long time. The freeze or pageVisibility events are
the best way to understand this.

Ryosuke: Can we pause mid-function if it’s not async?

Tim: Maybe if the computer is put to sleep. Not sure if this happens and in
which cases.

Todd: Edge took the position that performance.now should not be frozen as
far back as Windows 8.

Ryosuke: that’s what Safari does too.

Will: Is there a test that Firefox could use to double-check their behavior?

Yoav: No WPT, but there’s a JSFiddle attached to the issue that can help
testing

Nicolás: Does spec need to refer to sleeping PC to ensure performance.now
doesn’t stop?

Yoav: Probably a note.. And manual testing

Todd: Useful for each browser to run the manual test to confirm sleep and
background behavior

Gate Timestamps behind existing permission prompts

https://github.com/w3c/hr-time/issues/64
<https://www.google.com/url?q=https://github.com/w3c/hr-time/issues/64&sa=D&ust=1556052020672000>

Yoav: *summarize the issue*

Would like to close as this is a significant change to a widely used web
standard, with no implementer support

Ryosuke: Probably not the best way to approach this. So many other timers
exist.

Yoav: Many other mitigations that make an impact. COOP, CORP, CORB can
help. Blocking coarse timers won’t help.

Todd: This would be a hugely breaking change to the web today.

Ryosuke: If we implemented, it would be to lock precision unless
permissions. It turns out there are too many holes to plug this way.

Will: Mind keeping the issue open to poll Firefox folks till Friday?

Yoav: Sure

Find better sources to quote than Wikipedia

https://github.com/w3c/hr-time/issues/62
<https://www.google.com/url?q=https://github.com/w3c/hr-time/issues/62&sa=D&ust=1556052020673000>

Yoav: Moving the strict time to ECMA reference. Needs a review of the PR

Can HR-Time be moved forward?

Yoav: Can we move this to PR?

Phillipe: We should close the privacy issues, give them a week to see if
they push back, and then move forward.

Yoav: Any objections?

(Silence…)

Todd: Sounds great!

Performance-Timeline

Republish L2 based on the latest "level2" branch
<https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/124&sa=D&ust=1556052020674000>

Yoav: Can we republish the level2 branch as L2?

Philippe: Can do that today!

Yoav: Awesome!

Yoav: Also, all issues and tests seem to be green.

Navigation Timing
"timing allow check" is not well defined in the context of NavTiming

https://github.com/w3c/navigation-timing/issues/104
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/104&sa=D&ust=1556052020675000>

Yoav: Issue comment needs a review. The role of TAO for navigations seems a
bit inverse, as we need to protect the previous document or redirects from
the current document. This is not well defined currently.

Todd: Review by who?

Yoav: Todd/Anne/Ryosuke

Ryosuke: document can be created by script, and have no resource.

Yoav: In those cases, there’s also no previous document and no redirects.
So we can just check for those cases.

Ryosuke: and treat them like TAO wasn’t provided

Yoav: Yes. And when there is a previous document, we need that document to
opt-in to current origin. Same for redirects.

Ryosuke: Opting-in to the destination origin makes sense.

<out of time>


On Mon, Apr 22, 2019 at 10:42 PM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey all,
>
> Join us on the call tomorrow to discuss some outstanding issues!
> On the agenda we currently have:
>
>    -
>
>    Resource Timing
>    -
>
>       Specify TAO check for 304 responses
>       <https://github.com/w3c/resource-timing/issues/201>
>       -
>
>       Resource Timing and range requests
>       <https://github.com/w3c/resource-timing/issues/205>
>       -
>
>       Add tests for not-same-site nested context
>       <https://github.com/w3c/resource-timing/issues/204>
>       -
>
>       Test status <https://github.com/w3c/resource-timing/issues/71> (
>       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>
>       )
>       -
>
>    High-resolution Time
>    -
>
>       can performance.now() timers be frozen for background tabs, etc?
>       <https://github.com/w3c/hr-time/issues/65>
>       -
>
>       Gate Timestamps behind existing permission prompts
>       <https://github.com/w3c/hr-time/issues/64>
>       -
>
>       Can we ship?
>       -
>
>    Performance-Timeline
>    -
>
>       supportedEntryTypes: cache the FrozenArray
>       <https://github.com/w3c/performance-timeline/pull/118>
>       -
>
>       Buffered flag spec changes
>       <https://github.com/w3c/performance-timeline/pull/123>
>       -
>
>       Republish L2 based on the latest "level2" branch
>       <https://github.com/w3c/performance-timeline/issues/124>
>       -
>
>       Tests for L2 are green
>       <https://wpt.fyi/results/performance-timeline?label=master&product=chrome%5Bexperimental%5D&product=edge&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned>
>       !!
>
>
> The hangout link for the call will be the usual one
> <https://meet.google.com/nog-ttdz-myg?hs=122>.
>
> Cheers! :)
> Yoav
>
Received on Tuesday, 23 April 2019 19:43:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 23 April 2019 19:43:59 UTC