Re: WebPerfWG triage call: January 31st @ 11am PST

Thanks all who participated in the call.

Minutes are now available

Copying them here for safe keeping:
WebPerfWG meeting minutes - Jan 31st 2018

Participants: Nicolás Peña, Tim Dresser, Todd Reifsteck, Charlie Vazac, Nic
Jansma, Benjamin De Kosnik, Ryosuke Niwa, Ross McIlroy, Philippe Le
Hégaret, Yoav Weiss

Scribe: Nicolás

Yoav: now trying to record the calls.


Yoav: we’re very close to wrapping up various open issues. Issue 173 is
important, and there is a PR 197 to solve it. It changes behavior around
redirects and cross-origin redirects. Traditionally we require all
cross-origin redirects pass the TAO headers. To align with fetch, we’d like
to change that behavior so that, from the moment that we become
cross-origin in the redirect chain, all future requests must have TAO
headers. That’s a new and more strict requirement for the case of multiple
redirects: cross-origin and going back to same origin.

Nicolás: So same-origin resources have to whitelist themselves so ensure
that their timing info is reported.

Yoav: This is weird but it is what CORS is doing. This will enable us to
make TAO a subset of CORS. It’s a significant change to all implementations
so maybe this is an L3 change?

Todd: is this just for standard redirects or meta-redirects?

Yoav: just standard redirects.

Todd: so there seems to be no privacy concerns here.

Yoav: yes and that’s my understanding as well from talking to Anne.

Todd: if it hurts use cases, this might not be the right thing to do.

Yoav: yea but the purpose of this is to TAO to be implicitly be turned on
for anything that is cors-enabled.

Todd: could we just do an or: if TAO or CORS, then report timing.

Yoav: maybe but there are cases where you want CORS but not TAO.

Todd: so we’ll keep the key privacy implications for L2, but the
consideration about how to make it more like CORS will be punted to L3.

Ryosuke: could this affect the browser implementation in any way? Because
out-of-process resources would not want to be exposed.

Yoav: we’re talking about subresources, which don’t go into their own
process in Safari.

Ryosuke: but won’t necessarily stay this way forever.

Yoav: not aware of any conflicts there, but if it happens we should be made

Conclusion: split the current PR into the L2 bits and the L3 bits.

Yoav: regarding testing status, Chrome is almost green except for not
exposing subresources of no-cors cross-origin stylesheets. Other browsers,
not so green. Question for Mozilla and Webkit: could you make your
implementations greener by the end of the quarter?

Ryosuke: what is the problem?

Yoav: mostly issues with the tests regarding the buffering logic. Then
there’s other issues.

Charles: yes, buffering logic will all pass after I land a change on Webkit.

Ryosuke: what about supported entry types and resource_timing? Very generic

Yoav: resource_timing is an L1 test.

Charles: supportedEntryTypes landed recently on Webkit.

Ryousuke: Webkit and Gecko fail different test cases of that one but the
2-browser seems to be there.

Nicolás: we should probably split that test into parts, it has too many
tests in one file.

Yoav: there are some problems with the initiator type in

Ryosuke: this would not get fixed

Yoav: but the renderer is sending the request. You’d need to know if the
connection is being reused.

Ryosuke: we wouldn’t know, as this is all provided by CF network. Maybe
Gecko can fix this?

Yoav: would Gecko be able to fix these tests?

Benjamin: probably not gonna do Q1, Q2 would probably be better.

Todd: what’s the implication of failing these tests? Security or privacy

Yoav: most of them are not. But then, if we have two passing impls in each
of the tests, does that mean we pass the requirements?

Philippe: yes, especially if you know that other browsers will align, even
if it will happen later. The purpose is to have a clear spec.

Yoav (conclusion): AI to myself to figure out which test cases are not
passing in 2 implementations. Ryosuke and Benjamin, if there are still
failure, would it be possible to upgrade their priority?

Todd: we should at least have an agreement on the fix to push the spec


Yoav: issue 77 is the only outstanding one. What’s the issue?

Ryosuke: we need to define what ‘remain idle’ means.

Yoav: is it possible to link to the definition in the event loop proc
model, and then abstract that?

Ryosuke: but that defines when idle time starts, which is a different issue.

Todd: I think the key missing is that there is not definition for the timer
or any future scheduled work on any spec.

Ross: we need to query when the earliest of tasks queued on the event loop
will run.

Ryosuke: maybe audit the places where things are running in parallel.

Yoav: there’s a lot of things. It would be a very large specification

Ross: we’d have to do that, and the UA can reduce the deadline arbitrarily.
I think the intention is clear.

Ryosuke: I think the intention is not clear. We need a clear precise
definition of this.

Ross: I don’t think that the large spec project is worth the effort, since
we need to allow UA to have some leeway.

Ryosuke: but then the spec is useless, if we can give an arbitrary time.

Todd: the purpose of the spec is to make it clear to other implementers,
and if Ryosuke has questions then they should be resolved.

Ryosuke: for example, does main thread GC count? This is shared across all
the event loops.

Ross: yes but GC is not in any spec.

Yoav: we could add a non-normative note, but we can’t spec GC.

Todd: yea that seems to be in the spec already. So what is the confusion?

Ryosuke: what does it mean to remain idle?

Ross: maybe the wording is slightly wrong here. We can’t choose when it’s
going to remain idle since something else may come and schedule a task.
That’s fine, then the deadline is slightly wrong.

Ryosuke: so how does one compute this time at all?

Tim: can we refer to some notion of when the next task will be executed?

Ross: this is the problem, we cannot use HTML tasks.

Tim: maybe some notion of work on a CPU that would include tasks.

Ross: the spec should say “calculate the time when the next task is
scheduled on the event loop” but there’s no way to say this formally.

Ryosuke: that may be fine, but we still have to fix the timers.

Yoav: I think we have reached agreement on what we need to do with timers,
yes. We shall have a PR with the new definition. Question is: can we come
up with language which is precise enough, leaves room for heuristics, and
does not involve huge changes in other specs?

Ross: it should be a guess from the UA of how long you can continue running
until the UA needs to do more work.

Todd: is this time fixed?

Ross: fixed, but the UA is allowed to reset timeRemaining to 0.

Todd: and the UA has control over a lot of work that is not spec’d. I think
we want to make it better, we just need to find the appropriate wording to
make it a bit better.

Ryosuke: but there should be some minimum requirements. There’s a list of a
bunch of things that need to be taken into account.

Todd: I’m looking at step 5 and it looks like most of these are listed.

Yoav: yea so we already agreed that timer description there is wrong, since
it needs to be tied to the event loop and not the window.

Ryosuke: main thing missing is any tasks running in parallel. If these are
all the things, then expect to remain idle would not work, it cannot be
normative text.

Yoav: sure.

Ryosuke: and instead of saying internal tasks, just say
implementation-specific. Does Gecko take the next paint into account as

Ross: I think yes, at least in the case of rAF.

Todd: Edge did not finish, but we had a design that was planning to take
paint times into account.

Ryosuke: then we need to add that to the list.

Todd: oh yea because that is different from rAF callbacks.

Yoav: ok, Ryosuke maybe comment on the issue with things that need to be
added or not included. Then I will send a PR to change the wording.

Ryosuke: it’s not just concrete questions, I don’t know everything the
browser does.

Yoav: there are still things like GC which are not in spec.

Todd: but hunting for all the things that need to be included would be
hard, and things could be missed.

Ross: in Chrome, we didn’t have a list of a bunch of things. We added a
schedule in Blink, and all tasks for the renderer go to that scheduler. I
think Gecko did it the same way.

Benjamin: have to go, does not seem to be much consensus.

Yoav: time is up, next meeting is in 2 weeks.

On Wed, Jan 30, 2019 at 12:09 PM Yoav Weiss <> wrote:

> Hey all,
> Please join us on the next WG call to triage vs. issues and discuss their
> resolution. The call will use the following hangout link
> <>.
> Current agenda includes:
>    -
>    requestIdleCallback
>    -
>       "deadline" in the "start an idle period algorithm" should be
>       defined in terms of event loop
>       <>
>       -
>    Graduating Resource Timing L2
>    -
>       TAO model and redirects: #173
>       <> & #197
>       <>
>       -
>       Testing status
>       <>
>       -
>    Navigation Timing
>    -
>       8 open issues
>       <>
>       to discuss
> Feel free to add more items you want to discuss to the agenda doc
> <>
> .
> See y'all tomorrow :)
> Yoav
> P.S. As previously discussed, I plan to start recording the group's calls.
> Tomorrow would be my first attempt at that.

Received on Thursday, 31 January 2019 22:40:04 UTC