Yoav Weiss, Ryosuke Niwa, Steven Bougon, Nicolás Peña, Will Hawkins, Gilles Dubuc, Philip Walton, Eric Lawrence
Yoav: Ilya couldn't make it due to an offsite.
Todd is leaving the chair position in the group. We have basically decided to continue on with two chairs until the rechartering in May next year. Actively looking for candidates up until that point. So we'll send out a call for candidates at some point in the near future.
Otherwise, regarding moving the calls an hour earlier- some survivorship bias in asking the group on the call, but didn't hear any objections, so 10am PST moving forward. If there are problems in the future we can try to figure out a different time that works well for most people.
Yoav: What should it do was discussed at TPAC. Got feedback from Boris regarding the current definition and how we should improve it. Underlying question at TPAC: what do we want back-forward cache navigations to look like and what we want history navigations to look like.
Use case from Nic Jansma telling history navigations from regular navigations, but that doesn't tell us what we need to do for BFCache where document is being revived from BFCache and it has the previous entries in place.
Nicolás: What does the spec currently say?
Yoav: currently the spec refers to “traverse the history” which is true for every navigation. Wasn’t around when it was defined, but think it was intended for history-related pages and their loading times but also because NavigationType is back/forward but not necessarily BFcache related. Reasonable to expect it to have different characteristics vs. Navigate or a Reload operation. Also makes sense to distinguish BFCache from regular history traversal.
Nicolás: For the Back/Forward case which would be the timestamps that we would use? Some of them would not make sense when there’s no navigation?
Yoav: Maybe the shortest path forward would be to define a BFNav type as a part of L2? Or should we redefine the current “Traverse history by delta” as Boris suggested? Or define BackForward as a simple history navigation and tackle BFCache at a later point?
Philip: More context: Google properties want to measure how long it takes from the user clicking back for the page to show? Not currently exposed except in Safari which updates NavTiming L1 data. Useful for Google to get the info but no other browser exposes it. Can we expose how long it takes to come out of the BFCache and compare to a regular history navigation? This use case is not met by the current API. Can we either update it or add a new entry type?
Will: Seems to argue for adding a new NavigationType for BFCache that could pull that time out?
Nicolás: This would be different than BackForward as it exists today?
Philip: New entry dispatched by PerformanceObserver?
Yoav: Yes, I think that would be the cleanest solution. But as Nicolás pointed out there are various currently exposed attributes on that entry that don’t make sense. So we need to think about what each would mean in the BFCache case. But tangent issue that there are compatibility differences due to under-definition (Safari/Firefox).
For L1 it would make sense to align everyone to that.
Philip: Strong feelings about changing anything on the page in a getter on a global. Store a local reference and don’t expect it to change because it would be surprising if the value changed.
Yoav: You’re saying “The L1 entry values should not change?”
Philip: Yes.
Yoav: Yeah, modifying entries seems surprising and leaving other entries untouched seems weird.
Need to make progress on this issue and better define what the current BackForward type means. Maybe Philip or Nicolás could open a new issue indicating that we want to tackle the BackForwardCache case specifically. Only piece we need to agree on for L2 is about whether we want to change the already-dispatched entries. I tend to agree that we shouldn’t.
Perspective on current Safari behavior?
Ryosuke: Don’t know if intentional or a bug. Nothing useful to say here.
Yoav: Could you investigate whether it’s intentional for the group?
Ryosuke: Could you elaborate on the behavior?
Philip: Performance.timing.NavigationStart and some entries in the L1 specification (not PerformanceEntry) values get updated when page comes out of BFCache. And items that don’t apply are set to 0. In the pageShow event the eventTimestamp property isn’t set to the same as NavigationStart. Need to decide how browsers should set value.
Ryosuke: Load Page A. Nav to B. Back Nav to A. In Safari, Values updated when go back to A but not other browsers? Action Item Yeah, I can take a look. Please comment on Github issue directly and point to the change that allows us to do some archaeology.
Philip: Action Item: Open issue for new BFCache Type and new Entry. Need to define what the values for that entry would be.
Yoav: For issue 115: we need to do some work to define what non-BFCache case does here. Clarifying that this issue isn’t BFCache related was helpful.
Ryosuke: Looks like Safari behavior might be due to change in 2010 before the Blink fork happened. Something interesting happened there.
Yoav: Chromium doesn’t yet have a BFCache; work is in progress now to ship one.
Yoav: Not something we need to discuss. Add some hooks to HTML to enable storing state in relevant documents and read it from a getter. This is just work and work that is L2 blocking.
Nicolás: Spec definition of NavigationType Reload is unclear. Example where a user loads website then click in the address bar and hit Enter. For Chrome, it is treated as a reload (EricLaw: for NavigationType, not everything, see below).
So navigation type is set to reload. Some people filed a bug that this shouldn’t be treated as a reload as it wasn’t treated as a reload operation explicitly. Want clarification about correct behavior here.
(EricLaw: Firefox 69 does NOT treat Enter in the address bar as a NavigationType=reload (test page))
Yoav: The spec doesn’t define or link to a definition of “reload operation”. We need to have a better definition of what a reload operation is.
Implication for other features of “treated as reload”? Cache-Control headers? SameSite cookies?
Nicolás: Think it’s treated the same as the reload button
Eric: SameSite cookies may be impacted
Yoav: HTML might have a definition for “reload-triggered-navigation” we can use? Defined for the explicit .reload() method. “When a user requests that the active document be reloaded through a user-interface element, then …” But no definition of what the UI element is.
Whether user hits enter on the address bar or clicks reload button or hotkey, doesn’t seem web exposed or something that can impact web compat. Different browsers can do different things.
Nicolás: The navigation type “navigate” definition seem a bit contradictory in that entering a URL in the address bar counts as “navigate”.
Yoav: sure but in the case your talking about the user didn’t enter the URL
Nicolás: what about copy paste?
Yoav: Sounds like a UI decision that shouldn’t necessarily be in the spec? Spec should probably link to the concept of a “Reload triggered navigation” and define reload through that? But that won’t solve your issue.
Nicolás: It might if I can somehow figure out what entering on the address bar is. Suspect it’s a reload triggered navigation
Yoav: “UI element” sounds like something that’s explicitly vague
Nicolás: we would need to redefine the “navigate” type as well.
Yoav: Can we define it as Navigation operation that wasn’t a reload triggered nor history traversal? None of the others. About prerender, we need to kill it; not implemented anywhere. Which is another issue.
Will: Definition of a reload triggered navigation is in the otherwise section of what the reload method does on Location interface?
Yoav: Paragraph below that.
EricLaw: In Chrome. Hitting enter in the address bar is different than hitting Refresh for both sending of SameSiteStrict cookies and behavior for when you got to the page via a POST navigation. (Tests, see the footer for a NavigationTiming entry log)
Yoav: Do you know if those concepts are defined in spec?
Eric: Not sure.
Ryosuke: difference between reload from script and reload through UI?
Eric: UI, but this conversation started from the fact that different UI elements can trigger reload. That’s true for navigation type, but not necessarily true for at least two other aspects of “reload” vs. “navigate”
Yoav: so maybe we need multiple types of “reload triggered navigations” that define all those different behaviors
Ryosuke: Are those differences in Chrome intentional?
Yoav: It seems like a UI decision, but not 100% sure
Ryosuke: In the case of POST changing to GET, that’s not a reload operation but a different navigation. We don’t really define what kind of navigation was used.
Yoav: Good questions, but we don’t really have answers.
Ryosuke: Maybe we need a broader issue about what reload means.
Yoav: Do we need to address UI behavior in NavigationTiming? Can we just map to HTML reload-triggered-navigation concept?
Nicolás: But we don’t really know what it means.
Yoav: Currently it doesn’t really define behavior. We probably need a broader issue about the different behaviors that are triggered by different UI elements: POST vs. GET, SameSite cookies, etc. Need to figure out if those are mapped to a well-defined standard concept.
Nicolás: Which spec?
Yoav: HTML defines “reload-triggered navigation” so probably there. The flag sets a Fetch flag, but maybe we need multiple flags that perform those different behaviors.
Nicolás: Possible that some of these are attempts in optimization and are not meant to be defined
Yoav: Fetch doesn’t seem to be doing anything with this flag other than returning it in IsReloadNavigation. But seems like an HTML issue, not a navigation timing issue. Also need to see if other browsers are doing similar things. Worthwhile to write all these questions down in an issue.
Ryosuke: When a page fetched with POST then loads as using GET, that’s not a reload, but another navigation. If you were in a GET page and then changed methods to a POST page, that’s clearly not a reload, right?
Yoav: I agree. We can verify what Chrome and other browsers consider this, and see how it maps to HTML’s “reload-triggered navigation” concept. Worthwhile to test and figure out the rationale behind those UI decisions.
Nicolás: Action items?
Yoav: Map “reload” and “navigate” types to the “reload-triggered navigation” concept, but that doesn’t necessarily answer your question.
From a loading perspective, the differences between reload and navigate: E.g. Cache-Control headers with different loading characteristics. Probably want to report that regardless of how in the UI it was invoked.
Different UI elements do different reload-like things, maybe we want to define that, but seems out of scope for Navigation Timing.
Yoav: We modified the previous timingAllowed checks to be same-origin checks. There are various attributes on the entry that only get a value if same-origin to previous navigation. But right now that definition requires some cleanup.
Nicolás: What’s the correct fix? Do we want TimingAllowOrigin / SameOrigin checks?
Yoav: The TAO definition made it so that if you are browsing to a page, that page has control over whether it has access to various characteristics of the previous navigation. Didn’t make sense for the current page to be able to opt-in to get information on the previous page. Removed that in favor of a SameOrigin check. From what I see on the issue, there are a bunch of attributes that are still protected and shouldn’t be?
Nicolás: It’s confusing because in the NavigationTiming processing model they are not protected, but they link to the ResourceTiming spec for their definitions which do have the checks on their getters there. If I’m an implementer, what do I do? Should I do the checks?
Yoav: Spec bug.
Nicolás: Attribute getters should be trivial. In ResourceTiming, move the checks outside the attribute getters and run that only on the ResourceTiming processing model but not the NavigationTiming processing model.
Yoav: Or don’t link to RT spec from NT spec, and instead redefine these in NT spec without the checks? But that’s uglier, so we shouldn’t
Don’t want to redefine. Action Item (yoav): File an issue on RT proposing a flag where the TAO-check is bypassed, and set that bypass flag when calling from NavigationTiming.
Nicolás: SecureConnectionStart is also linking directly to RT which seems incorrect for the same reason.
Yoav: yeah, we consolidated the definitions, but looks like we consolidated too much.
Yoav: A few requestidlecallback issues: Excited to see Ryosuke making progress there. Out of time to discuss.
Nicolás: Invite Ross Mcilroy to the next call to get answers. Take this up on the next call.
If blocked, could set up an earlier call?
Ryosuke: Not necessarily blocked. Could just implement best guess. But would be good to talk before next scheduled call.
Yoav: Thanks! Next call on Oct 31st, 10AM PST. Halloween? Might not work well for folks. Will send an email to reschedule.