Partytown breaks VT fallback

[florian-lefebvre]

Astro Info

Astro                    v3.3.2
Node                     v18.14.1
System                   Windows (x64)
Package Manager          yarn
Output                   static
Adapter                  none
Integrations             @astrojs/mdx
                         @astrojs/sitemap
                         @astrojs/partytown

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

When creating a partytown script and navigating to a new page in an unsupported browser (like firefox), VT breaks: url is not updated, event listeners are not triggered etc but page swaps. See video.

Astro.Blog.Firefox.Developer.Edition.2023-10-18.15-48-05.mp4

What's the expected result?

Shouldn't break

Link to Minimal Reproducible Example

https://github.com/florian-lefebvre/astro-vt-fallback-bug

Participation

• I am willing to submit a pull request for this issue.

[martrapp]

Help wanted! Obviously the minimal example does not work for @florian-lefebvre, but I was not able to reproduce the error with Firefox. Who can help to identify the source of this behavior?

[lilnasy]

I can reproduce the issue. I could take a closer look later this week.

video.mp4

[lilnasy]

Affects firefox only, not Safari.

https://bugzilla.mozilla.org/buglist.cgi?quicksearch=NS_ERROR_NOT_INITIALIZED

[alan-barzilay]

I also got the same issue, firefox + partytown + VT

[lilnasy]

This one might be hard to debug. The Firefox-specific error does not provide a stacktrace. I'm pretty sure it has to do with Partytown's usage of low-level APIs (Atomics, SharedArrayBuffer) that exposes a memory-management bug in Firefox, but there is no straightforward way to confirm.

[lilnasy]

Workaround: turn off minification.

import { defineConfig } from 'astro/config';
import mdx from '@astrojs/mdx';
import sitemap from '@astrojs/sitemap';

import partytown from "@astrojs/partytown";

// https://astro.build/config
export default defineConfig({
  site: 'https://example.com',
  integrations: [mdx(), sitemap(), partytown()],
+ vite: {
+   build: {
+     minify: false
+    }
+  }
});

[florian-lefebvre]

Do you think it's worth opening an issue usptream or is it really caused by Astro?

[florian-lefebvre]

I deployed a vercel preview with your suggested workaround because it didn't work locally, and it didn't work either. You can check it out at https://legismusicastro-lfkizaw6x-legis-music.vercel.app

[lilnasy]

Do you think it's worth opening an issue usptream or is it really caused by Astro?

I'm not sure yet. Since, view transitions are necessary for it to break on Firefox, there might be a fix possible on Astro's side. Just as long as it's not too drastic.

[lilnasy]

Using a build of partytown with minification turned off pointed me to a single line.

Partytown patches the History API, and its code runs whenever the History API is used. It seems like an issue for Firefox to fix, although Partytown may be able to remove this hacky code. Astro's usage of history API is necessary and proper.

[lilnasy]

Reducing priority only because it is a signal astro maintainers use to pick up issues. This is not something for them to fix.

[emish89]

I created the bug here, maybe this can help:
QwikDev/partytown#505

[lilnasy]

• An issue has already been open for a month: [🐞] Firefox + Patytown + Astro View Transitions breaking links QwikDev/partytown#486
  Partytown does not seem to be actively maintained.

[matthewp]

Might be able to prevent it by stopping Partytown from highjacking pushState, going to give that a try.

[matthewp]

Looks like that will work.

[emish89]

@matthewp can you post a code snippet?
in this way we are losing GA events, correct?

[matthewp]

@emish89 I can create a preview release for you to try. You might lose events, I'm not sure. Hopefully not.

[matthewp]

@emish89 could you try out astro@experimental--vt-partytown and let me know?

[emish89]

ok tomorrow I'm going to try.
I also created a PR in partytown that should solve :/
QwikDev/partytown#511

[matthewp]

@emish89 have you confirmed that removing the setTimeout does fix it?

[lilnasy]

It was not sufficient to prevent the failure when I tried it. It has been a while though, it's possible I missed something.

[emish89]

in my local worked, but for sure I'm not an expert of the package. If they put it, is because there was some reason...

@lilnasy do you remember what can I test to be sure if is working or not?

[lilnasy]

If firefox does not error anymore then disregard what I said. The only tests to worry about would be the ones in partytown repo.

[matthewp]

@emish89 did you get a chance to try out astro@experimental--vt-partytown?

[emish89]

I would say that is working, for sure is not breaking, but I'm not 100% sure if is sending data to GA.
I cannot install extensions to check that on firefox

[matthewp]

Ok, I'm going to suggest that we go with this then. The most important thing is that page navigation is not broken. If Partytown is causing it to be so, then the priority should be for us to avoid that.

[emish89]

Ok, I'm going to suggest that we go with this then. The most important thing is that page navigation is not broken. If Partytown is causing it to be so, then the priority should be for us to avoid that.

totally understandable and I agree. I confirm that in my case is now not breaking with this version.