Issue with hashChange determination for NavigateEvent when dispatched through replaceState/pushState

[rwlbuis]

What is the issue with the HTML Standard?

When looking at for example navigate-event/navigate-history-pushState.html, the test expectation for hashChange is false. However from looking at the specification it should be true. It seems when using History API the determination is different, yet this does not seem reflected in the specification AFAICS.

[domenic]

My instinct here is that the test and Chromium's implementation is wrong, and we should update them. I cannot find any evidence of this being intentional.

[rwlbuis]

My instinct here is that the test and Chromium's implementation is wrong, and we should update them. I cannot find any evidence of this being intentional.

That plan would align well with WebKit's current implementation.

[domenic]

I started working on this and then I had second thoughts. I think this might have been intentional after all.

The original explainer states:

hashChange: a boolean, indicating whether or not this is a same-document fragment navigation.

Additionally, a large amount of example code does stuff like

navigation.addEventListener("navigate", e => {
  if (e.hashChange) {
    // Assume this is the user clicking on a fragment link and ignore it.
    return;
  }

  // Otherwise, process this with navigation interception.
});

I think changing how such code reacts to history.pushState("/#fragment") might cause compat problems. Worse, I think it might make it harder for people to write nice apps that use the navigation API.

So now I am thinking we should update the spec to match Chromium's behavior and the tests... I am open to being persuaded otherwise, especially by web developers with experience using the navigation API. But I'll tentatively proceed with a spec patch.