Type Error: illegal invocation
Which project does this relate to?
Router
Describe the bug
Hi, I am using the following packages
@tanstack/react-router": "^1.117.0
vite: "^5.4.8
@tanstack/router-plugin": "^1.117.0
I am using file based routing, and in production I am getting this illegal invocation error for some of the users. I couldn't reproduce this but according to sentry it's happening for some of the users.
const flush = () => {
if (!next) {
return;
}
history._ignoreSubscribers = true;
(next.isPush ? win.history.pushState : win.history.replaceState)( // This is where it happens
next.state,
"",
next.href
);
history._ignoreSubscribers = false;
Following sentry stacktrace, when user clicks on one of the links in the app that redirects to another page ( using navigate and both pages are within my app, tanstack router ) it crashes due to illegal invocation.
My vite config:
export default defineConfig({
// depending on your application, base can also be "/"
base: "/web",
plugins: [
TanStackRouterVite({ target: 'react', autoCodeSplitting: true }),
react(), svgr(), mkcert(),
sentryVitePlugin({
org: "****",
project: "****",
authToken: "****",
}),
],
build: {
outDir: "build",
sourcemap: true,
minify: 'esbuild'
},
preview: {
port: 3000,
},
server: {
https: true,
// this ensures that the browser opens upon server start
open: true,
// this sets a default port to 3000
port: 3000,
},
resolve: {
alias: {
components: path.resolve("./src/components"),
core: path.resolve("./src/core"),
assets: path.resolve("./src/assets"),
pages: path.resolve("./src/pages"),
hooks: path.resolve("./src/hooks"),
layouts: path.resolve("./src/layouts"),
},
},
assetsInclude: ["**/*.webp", "**/*.png", "**/*.jpg"],
})
Thank you in advance for your help.
Your Example Website or App
Steps to Reproduce the Bug or Issue
Open the app
Click on one of the buttons that uses navigate ({to : url})
Crashed due to illegal invocation.
This flow was sentry stacktrace and I can NOT reproduce it but it's happening to the users ( more than 50 events and 40> unique users )
Expected behavior
Expected to navigate to the specified url but it crashes due to illegal invocation error
Screenshots or Videos
Platform
-
OS: Windows
-
Browser: Chrome
-
Version: 136.0.0
-
Brower: Firefox
-
Version: 138.0
-
Browser: Edge
-
Version: 136.0.0
Additional context
No response
since you mention 3 browsers, are those the ones that sentry reported the error for?
Yes, but it's not limited to these browsers; these are just the versions where most errors were detected. We also have errors for Chrome 135.0.0 and other browser versions. I haven't noticed anything on Safari yet.
This is my first time opening an issue on GitHub, and I'm unsure how to provide more useful information for this issue. However, I'm fully available to assist if someone can guide me on what to do to help. Thanks.
are you using any library / script that also hooks into window.history somehow? maybe for tracking or analytics?
Aha, yes I think you found the issue, we're using smartlook, I just looked into the scripts it downloads and runs and looks like they're proxying history pushState on some currentWindow. since it's a bundled script I can't say if it's the main document window or something else, but this could be the main problem with a high probability, I will try to bypass smartlook for a few days and see if the error happens again, and then I'll update the issue here. thank you for your help.
Just a fun fact: Illegal invocation coming from when methods that depend on being bound to window are bound to the proxied version of window. Those window methods will do a brand check on this and check if window === globalThis and if its not it will throw that error.
I ran into an issue where multiple libraries were intercepting and proxying the window history. In my case, there were two libraries causing this behavior. It looks like developers are building this functionality into their libraries, and unfortunately, I depend on these for my work. After checking Sentry's replay data, I noticed that even though the error occurs, the app doesn’t actually crash. Given that, and the amount of work it would take to fix, I’m okay leaving it as is for now. For anyone who might find it helpful, here’s the full stack trace from Sentry.