Allow Google Analytics to detect page changes based on browser history events when using <ClientRouter />

[jonasgeiler]

The Problem

I am currently trying to integrate Google Analytics into my site. I am using the Client-side Router (SPA mode) of Astro and due to that, I turned on detection for Page changes based on browser history events in the "Enhanced measurement" section of the Google Analytics settings. This way, calls to pushState, replaceState and popState are detected and cause page_view events.

However, I noticed that Google Analytics is unable to detect my page navigations. The only event it can detect is going back in history with the back button, because that is an actual browser event, and not a wrapped History API function.
I looked deeper into it and I think the problem lies with Astro caching/saving a bind to the history.pushState and history.replaceState methods in router.ts:
https://github.com/withastro/astro/blob/af83b85d6ea1e2e27ee2b9357f794fee0418f453/packages/astro/src/transitions/router.ts#L25-L27

An Example demonstrating the Problem

Here is also an example script showing the behavior of gtag.js's monkey-patching of History API function, and where the problem lies:

// Simulate History API
const _history = {
  pushState() {
    console.log('pushState called');
  },
};

// Different ways to wrap the pushState method
const pushStateBind = _history.pushState.bind(_history);
const pushStateDirect = _history.pushState;
const pushStateWrapper = (...args) => _history.pushState(...args);

// Test call the functions before gtag.js monkey-patching simulation
_history.pushState();
pushStateBind();
pushStateDirect();
pushStateWrapper();

// Simulate gtag.js event function
function gtag() {
  console.log('gtag called');
}

// Simulate gtag.js monkey-patching the history.pushState method
const h = _history;
const hps = h.pushState;
_history.pushState = function () {
  hps.apply(h, [].slice.call(arguments, 0));

  // Simulate gtag event tracking
  gtag('event', 'pushState', {
    event_category: 'History',
    event_label: 'pushState called',
  });
};

// Call the functions again after gtag.js monkey-patching
console.log();
_history.pushState(); // Logs 'gtag called'
pushStateBind(); // NOT LOGGING 'gtag called'!
pushStateDirect(); // NOT LOGGING 'gtag called'!
pushStateWrapper(); // Logs 'gtag called'

As you can see, pushStateWrapper() is the only one that works, apart from calling it directly.

My Proposed Changes

It would be working properly if Astro is not caching/saving the pushState and replaceState methods in a variable, but instead calls history.pushState and history.replaceState directly every time.
That's why I would like to propose to change the three lines in router.ts to something like this:

const pushState = (inBrowser && ((...args) => history.pushState(...args))) as typeof history.pushState;
const replaceState = (inBrowser &&
	((...args) => history.replaceState(...args))) as typeof history.replaceState;

Depending on how Astro's build tools are set up this might need some TypeScript adjustment, but testing it with the latest TypeScript Playground version, I got no warnings/errors.
I am also not sure if inBrowser && ... was even a good idea in the first place, since you can't call a boolean? But I'm gonna leave that as-is.

I'd be happy to create a PR myself, if this gets approval!
Should be a rather simple change.

[jonasgeiler]

I just noticed that the comment above those lines says

Create bound versions of pushState/replaceState so that Partytown doesn't hijack them,
which breaks Firefox.

Now I am not sure how to solve this for both Partytown on Firefox, and Google Analytics...

[MoustaphaDev]

I think a refactor that would unlock this use case would be great! I'd consider this a fix, as it's apparently the way we use the history object that breaks Google Analytics. So I think you could directly send a PR, but let's see what other maintainers think.

[martrapp]

Hi @jonasgeiler, @MoustaphaDev 👋🏼,

I would be happy to revert the code to the simpler version that we had before withastro/astro#9419. So the hope is that 1.5 years changed a lot to the better for Firefox and Partytown? Or will that reopen withastro/astro#8862?

[jonasgeiler]

It's definitely worth revisiting this issue.
Partytown went through many changes, and the issue reported to Partytown was also fixed.

If I find the time I will try out the repo reproducing the original issue.

[jonasgeiler]

@martrapp @MoustaphaDev

Alright, so I tried out the bug report repo at https://github.com/florian-lefebvre/astro-vt-fallback-bug, and I was able to reproduce the issue in Firefox 139.0.4.
And, after running yarn install @astrojs/partytown@latest, the bug seems to have disappeared.
Looks like it was indeed fixed somewhere down the line!

I also saw that withastro/astro#9419 was merged 15 days BEFORE QwikDev/partytown#511 was merged. I suppose Partytown fixed it in that PR, but Astro never followed up on it?

I'm relatively confident that we can revert withastro/astro#9419 in some capacity. But I will leave that up to the maintainers to decide.

[jonasgeiler]

@martrapp @MoustaphaDev Any updates? Been a while...

[Fryuni]

I'll create an issue from this discussion so it doesn't get lost. Old discussions can be forgotten, but issues are frequently re-triaged.

[Fryuni]

withastro/astro#14282