- From: Yoav Weiss <yoav@yoav.ws>
- Date: Thu, 31 Jan 2019 23:39:21 +0100
- To: public-web-perf <public-web-perf@w3.org>
- Message-ID: <CACj=BEi2c2SV+Czw-5Fuh3JLz955t=ZtuUqSS2UFx0=0qscb6A@mail.gmail.com>
Thanks all who participated in the call. Minutes are now available <https://docs.google.com/document/d/e/2PACX-1vTZx36LdGIskM4gKDI5k-Jw95KewaMoDl7n71H6X8HiZT1jVNnfA2S4HwCP_fwOOFai8lGqcSp4ARAP/pub> . 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. 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. On Wed, Jan 30, 2019 at 12:09 PM Yoav Weiss <yoav@yoav.ws> 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 > <https://meet.google.com/nog-ttdz-myg?hs=122>. > > Current agenda includes: > > - > > requestIdleCallback > - > > "deadline" in the "start an idle period algorithm" should be > defined in terms of event loop > <https://github.com/w3c/requestidlecallback/issues/71> > - > > Graduating Resource Timing L2 > - > > TAO model and redirects: #173 > <https://github.com/w3c/resource-timing/issues/173> & #197 > <https://github.com/w3c/resource-timing/pull/197> > - > > Testing status > <https://wpt.fyi/results/resource-timing?label=master&label=experimental> > - > > Navigation Timing > - > > 8 open issues > <https://github.com/w3c/navigation-timing/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22discuss%22> > to discuss > > > Feel free to add more items you want to discuss to the agenda doc > <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.ka4e719cmjl4> > . > > 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