Participants
Giacomo Zecchini, Nic Jansma, Yoav Weiss, Patrick Hamann, Annie Sullivan, Steven Bougon, Michal Mocny, Nicolás Peña Moreno, Sean Feng, Carine Bournez, Benjamin De Kosnik,
Next Meeting - June 24th 10am PST
Minutes
Nic: Plan for today is triage.
- Nic: Marcos suggesting a PR template for all repos. Has a suggested template in https://github.com/w3c/hr-time/pull/121/files
- ... Starting point for pull requests. Thoughts on things included? Other things we should add?
- ... Will propagate that throughout the repos
- Nicolás: Maybe a field for PRs that are not implementation changes?
- Yoav: “editorial” vs. “breaking change”
- ... Maybe we can add “change” vs. “breaking change”
- ... Different field for backward-compat that requires more significant input
- Nicolás: Need to make the difference clear between “chore” and “editorial”. We should add a short description.
- Michal: Should have commitments before opening a PR?
- Yoav: No, need to have it for landing for changes and breaking changes
- Michal: I don't want anyone to not open a PR because they don't have commitments yet
- Nicolás: Top says this is only for normative changes. Unclear where editorial and chore fits.
- … Also want to not discourage people from submitting PRs. Need to clarify what fields are not require for submitting the PR.
- Nic: Captured all in a comment on the issue. Once we get it merged in, we can duplicate it further.
- Nic: Talked about new types of navigation, this App History API allows you to specify Soft Navs
- Yoav: For some background, Domenic and others are working on a new App History API that allows better control over what a Soft Navigation is, and enables the browser to know when an intent for Soft Nav is happening
- ... Today developers intercept a random click event and pushState a random URL change, there's no clear way to say a navigation has started or ended
- ... App History gives clear time it was started, whether it was user-initiated or not
- ... Includes a promise-based API developers can resolve whenever they feel it has been completed
- ... Domenic suggest a new PerformanceEntry, SameDocumentNavigationEntry, just has a boolean success
- ... Time difference between start time and when it was resolved
- ... A lot of the attributes for regular navigations aren't aren't appropriate for Soft Navs, e.g. network timings
- ... At the same time similar for BFCache navigations, we were trying to have all the same nav types need a single listener
- ... Do we want separate observers for separate navigation types?
- ... One option that Domenic mentioned that could be interesting, is a single keyword that allows you to navigate all of those different navigation types, but still entry types for each
- Nic: For clarification, instead of .observe(navigation) you would do .observe(all-navigations)
- Yoav: Yes, you could do that or .observe(bfcachenavigation) or all types
- ... From back-compat, we looked at extending navigation array and it is web-compatible, but it's possible some of that code looks at PerformanceNavigationTimingEntry and will get confused if it other types are in the array
- Michal: If the goal is throwing them into a single bucket only to know when it's time to slice all entries, but then visibility- or idleness- of sessions gets thrown in. If not, if it's narrowly focused on navigations, the difference between BFCache and AppHistory is the URL changes. And there's one property I would want to handle specifically for BFCache.
- Yoav: I think slicing isn't the reason here as we can have Navigation IDs with a counter that tells you for other entries which Navigation ID it correlates with.
- ... Hadn't considered adding visibility to having a new Navigation ID, but it doesn't necessarily impact the API shape
- Michal: Is it possible to get the URL in the case of a App History navigation? I didn't see it in the proposal
- Yoav: Yes, I hadn't seen URL as part of the entry. Entry should provide that attribution, meaningful for developers that are collecting it
- ... I haven't heard any strong opinions on API shape
- Yoav: AI for anyone with an opinion to go to the PR and comment https://github.com/WICG/app-history/pull/125
- NPM: Is the idea to also surface this for back-forward navigations?
- Yoav: Different from SameDocument, we would use a different type for BFCache navigations
- ... Either we take that shape for SameDoc navigations as well, or BFCache is yet another navigation entry
- NPM: This and BFCache navigations seem similar in the information we would provide
- ... Most attributes for regular navigations are about network
- Yoav: This currently provides a success boolean, and it should provide a URL. Duration defined on the promise, where I'm not sure BFCache should provide a duration.
- NPM: I guess we need to answer that question, do we need same entry for App History vs BFCache vs regular nav vs Portal navigation
- Yoav: Yeah that is exactly the question
- Michal: Beyond downside to having to register multiple observers, if we're going to register Navigation ID for all, you would need to monitor for all to be correct.
- ... And do we need a Navigation ID or just a timestamp?
- Yoav: Times can overlap, we want an ID if possible
- Michal: If at all possible the ID was the index into all
- Nic: Future-proofing by having them all in a single observable array is better than telling developers to listen to A B C types and then us later adding a D type they're not listening to.
- Yoav: Tradeoff of visibility vs. fitting all navigations into a single type
- AI: Open a new issue in NavigationTiming or PerformanceTimeline to coalesce different types
- Yoav: Proposal is to use initiatorType and have value of initiatorType be early-hint
- ... Has side effect of being transparent from RT spec perspective, it just needs after Fetch integration for the caller to Fetch to pass-along early-hint as initiatorType and that will be reported
- ... I think it's a good solution to that problem
- ... Background is Chrome is playing around with early-hints Origin Trial
- ... One of the requirements is to be able to measure if early hints were used, as part of Origin Trial
- ... Doesn't involve a spec change here, just in Early Hints
- ... If OT is successful, and Chrome decides to implement and ship, this is the right way to report
- Nic: Is there any info lost from initiatorType when using it here?
- Yoav: initiatorType is not super useful here, i.e. for Preload it's reported as LINK
- ... No information loss
- Sean: When I was looking at this the concern I have is Early Hints is a Chrome-only feature, exposing something that only exists in Chrome sounds like no the right solution
- Yoav: EH is no browser feature yet, it's an IETF standard, but no web spec for it at the moment
- ... I know the Chrome loading team is planning on working on one
- ... Needs Fetch integration to see how it interacts with CSP and other things
- ... Right now it's in an Origin Trial, being experimented, not yet web exposed
- ... When its' web-exposed, the current typing of ResourceTiming aligns well with the caller passes along to the algorithm what the initiatorType is, so this doesn't require any real changes on the RT front. Just caller to Fetch spec.
- ... Supplemental feature for H2/Push
- ... Basically the Chrome Loading team is playing around with it to see what it gives
- ... The experiment would enable various partners to report back performance improvements or otherwise
- https://datatracker.ietf.org/doc/html/rfc8297
- AI: Yoav to close the issue since it'll happen in Fetch
- Nic: Opened by Anne, to use ByteString as part of the IDL
- … In our spec nextHopProtocol requires an isomorphic decode and changing the IDL to a ByteString would avoid that extra step
- Yoav: Can take an AI to see what it actually means
- Yoav: AI to talk to Marcos and see what that means
- Nic: Marcos is suggesting that the change was intentional
- NPM: How it's improperly specified for NavigationTiming and IFRAME resources because they go through different navigation path in Fetch spec than other resources
- ... Because they start as a navigation
- ... I think we agree what the thing needs to do, we just need to specify if
- ... It shouldn't have a different behavior than say an IMG, i.e. go through all redirect hoops
- ... Unfortunately we don't get that for free in Fetch because IFRAMEs go through a different path
- ... From when we made the move to the TAO check in the Fetch Spec, and we haven't yet fixed it
- Yoav: For NavigationTiming it doesn't matter because TAO doesn't apply, but for IFRAMEs need to report TAO to the parent
- NPM: Hopefully implementers are implementing it like Chrome does which is to not treat it like a different case
- Yoav: I don't think we have test for TAO checks for IFRAMEs
- NPM: Maybe that's the first step, to see how browser vendors are aligned
- Yoav: Change but not a breaking change
- ... Agree if we are all aligned that would reduce the urgency
- ... I think the TAO tests are not using IFRAMEs
- ... They're using sync XHR for some reason
- ... There's an ongoing effort to improve the tests, I think part of it is we want to expand the test surface to check different types of resources
- ... Images at least in Chromium are different types of loaders and IFRAMEs are different beasts
- ... First step is to expand tests to also cover IFRAMEs
- ... See how big problem is
- Nic: Any volunteers to work on tests?
- Yoav: FWIW I think it will be easy
- ... New test framework for all the old TAO tests are now this list of tests and using sync XHR, testing the IFRAME case would just add an array here of adding loading functions and iterating over that array with test cases
- ... Results should be the same
- Nic: AI on Yoav or Nicolás to see if their teammate's refactoring work will be covered here, if not someone in the WG can help