Re: WebPerfWG triage call - Thursday October 17th @ 10am PST

Thanks all who attended yesterday's meeting. Minutes
<https://docs.google.com/document/d/e/2PACX-1vSgRgRCjw2MUQYcmFVEHYktcXNLyL5XZTqIhfS3ERGIwFgtLr9lPHEK1wu7IfWi_S1DbDtGcIv8BaQW/pub>
and video <https://youtu.be/Xqp_qKBIupU> from the call are now available.

Posting the minutes here for safe keeping:
WebPerfWG triage call - October 17th 2019
Participants

Yoav Weiss, Ryosuke Niwa, Steven Bougon, Nicolás Peña, Will Hawkins, Gilles
Dubuc, Philip Walton, Eric Lawrence

Administrivia

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.

Navigation Timing

Navigation type and BF cache
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/115&sa=D&ust=1571394157327000>

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.

------------------------------

Processing model for nav timing doesn't match reality
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/114&sa=D&ust=1571394157335000>

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.

------------------------------

Definition of reload
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/116&sa=D&ust=1571394157336000>

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
<https://www.google.com/url?q=https://webdbg.com/test/cookie/samesite/&sa=D&ust=1571394157338000>
))

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
<https://www.google.com/url?q=https://html.spec.whatwg.org/%23the-location-interface:reload-triggered-navigation-2&sa=D&ust=1571394157339000>”
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
<https://www.google.com/url?q=https://html.spec.whatwg.org/%23the-location-interface:reload-triggered-navigation-2&sa=D&ust=1571394157341000>
.

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
<https://www.google.com/url?q=https://webdbg.com/test/cookie/samesite/&sa=D&ust=1571394157341000>,
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.
------------------------------

Rethink former-TAO limitations
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/117&sa=D&ust=1571394157345000>

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.



On Tue, Oct 15, 2019 at 9:51 AM Yoav Weiss <yoav@yoav.ws> wrote:

> Hey folks!
>
> Hope everyone recovered from the TPAC F2F and excited to talk about
> WebPerf again! :)
> This Thursday on the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.3qk2of9rwqo4>
> we have:
>
>    -
>
>    Navigation Timing
>    -
>
>       Navigation type and BF cache
>       <https://github.com/w3c/navigation-timing/issues/115>
>       -
>
>       Processing model for nav timing doesn't match reality
>       <https://github.com/w3c/navigation-timing/issues/114>
>       -
>
>       Definition of reload
>       <https://github.com/w3c/navigation-timing/issues/116>
>       -
>
>       Rethink former TAO limitations
>       <https://github.com/w3c/navigation-timing/issues/117>
>       - requestIdleCallback
>    - Idle callback order
>       <https://github.com/w3c/requestidlecallback/issues/82>
>       - The invoke idle callbacks algorithm should check if list of
>       runnable idle callbacks is empty or not
>       <https://github.com/w3c/requestidlecallback/issues/83>
>
>
> Feel free to add items to that if there's anything else we need to discuss!
>
> As always, *the call will be recorded and posted online*.
>
> See y'all on Thursday!
> Yoav
>