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.

ResourceTimingL2

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 aware.

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 name.

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 resource_connection_reuse.

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 related?

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 forward.

RequestIdleCallback

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 project.

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 well?

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.