Intercepting a `pushState` triggers `popstate`
kurtextrem opened this issue · 2 comments
Hi,
Currently, in Chromium, when intercepting a history.pushState call that would normally not trigger a popstate event, it will trigger the popstate event. This impacts tracking, as e.g. GTM and GA like to run on both popstate and history.pushState/replaceState, thus leading to duplicate events being tracked when selecting "History change" as tracking variable.
Is that intended? The explainer does not really mention the interaction between popstate and intercepting.
This appears to be a Chromium bug. Nothing in the full formal spec (which is now in the HTML Standard) would cause this.
I checked our web platform test coverage and can't find any tests of this scenario. There are lots of tests checking that popstate is fired correctly when you do a back navigation, including an intercepted one, or one that goes back to a state that was previously created by pushState(). But nothing checking the popstate behavior for just a plain pushState().
Please file a bug at https://crbug.new, and either CC domenic@chromium.org (if that's an option) or drop a link here (if it's not). Please include a small test page. We should be able to fix it quickly.
Hey domenic, thank you for taking care so fast! I opened a bug: https://issues.chromium.org/issues/352436133