Issue with hashChange determination for NavigateEvent when dispatched through replaceState/pushState about html HOT 3 CLOSED

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.

from html.

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.

from html.

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.

from html.