search

w3c / navigation-timing

Navigation Timing
https://w3c.github.io/navigation-timing/
Other
116 stars 30 forks source link

Spec for PerformanceNavigationTiming.type does not match any implementations #114

Closed bzbarsky closed 2 years ago

bzbarsky commented 5 years ago

The spec at https://w3c.github.io/navigation-timing/#dom-performancenavigationtiming-type says:

The type attribute MUST return a DOMString describing the type of the last non-redirect navigation in the current browsing context.

That means that it returns the same value for all navigation timing instances for windows that were loaded in that browsing context, right? But that's not what any UA implements. Consider this testcase:

<body>
<script>
  function makeURL(str) {
    var blob = new Blob([str], { type: "text/html" });
    return URL.createObjectURL(blob);
  }

  var ifr = document.createElement("iframe");
  ifr.src = makeURL('<button onclick="parent.navigate()">Click me</button>');
  document.body.appendChild(ifr);

  var oldTiming;

  function navigate() {
    oldTiming = frames[0].performance.navigation;
    ifr.src = makeURL('<button onclick="parent.doReload()">Now click me</button>');
  }

  function doReload() {
    ifr.onload = function() { alert(oldTiming.type + " " + frames[0].performance.navigation.type); }
    frames[0].location.reload();
  }
</script>

Load the testcase, click the "Click me" button, then click the "Now click me" button. Per spec, it should alert "1 1". It alerts "0 1" in Firefox, Chrome, and Safari. And in general, it would make more sense if the timing instance for a given window/document (whatever that means) reported information about that window/document's load, not about other loads. So the UA behavior does not seem unreasonable at all.

If the spec gets changed to have this state tied to something other than the browsing context, then we should make sure to consider how the new definition of the type attribute interacts with bfcache: should a page coming out of bfcache end up with "back_forward" or with whatever value it had before going into bfcache?

@bdekoz

hawkinsw commented 5 years ago

Just to clarify the problem with associating the type attribute to the browsing context rather than the document, according to the spec the output in your example should be "1 1" because when the type attribute is fetched from oldTiming it will refer to the "last non-redirect navigation in the current browsing context" which is the reload() of the iframe?

According to this, if I fetched the type attribute of oldTiming from the context of the outer document after the invocation of doReload() I would expect the value to be 0 because the last navigation in that browsing context was the initial load of the page?

bzbarsky commented 5 years ago

So there's the separate question of what "current browsing context" means. The spec uses this wording in multiple places but never defines it. It would be good to define it, yes. Presumably it's meant to be the responsible browsing context of some script settings object, but which one? The current one, the relevant one, something else?

bzbarsky commented 5 years ago

One other bfcache-related issue. Per HTML spec, in the bfcache case there isn't a "navigation" at all. Just a history traversal; see https://html.spec.whatwg.org/multipage/browsing-the-web.html#traverse-the-history steps 2 and following, which is directly invoked from https://html.spec.whatwg.org/multipage/history.html#traverse-the-history-by-a-delta

toddreifsteck commented 5 years ago

@hawkinsw Could you add a PR for this behavior to the existing navigation timing tests?

yoavweiss commented 5 years ago

@bzbarsky - I agree that the definition is wrong, and defining type to be based on the document makes perfect sense. Would defining it as the "last non-redirect navigation in the responsible document of the context object's relevant settings object" work? (while adding something like your test case as a WPT)

P.S. Neat use of Blob URLs to avoid spreading tests between different documents. We should probably use this more often for NT/RT tests.

bzbarsky commented 5 years ago

last non-redirect navigation in the responsible document

Navigations don't happen "in" a document....

Imo the right way to fix this is to work with the HTML spec editor to have navigation store whatever the relevant state is in the relevant documents and then read this state in the getter here.

yoavweiss commented 2 years ago

@noamr - Can you take a look at this to see if this was covered by recent tests?

noamr commented 2 years ago