Uncaught DOMException: Failed to execute 'querySelectorAll' on 'Element'

[mkotsollaris]

Verify canary release

• [X] I verified that the issue exists in the latest Next.js canary release

Provide environment information

Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.16.1
      npm: 9.5.1
      Yarn: 3.5.0
      pnpm: 7.27.0
    Relevant Packages:
      next: 13.4.8
      eslint-config-next: 13.3.0
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.0.2
    Next.js Config:
      output: N/A

Which area(s) of Next.js are affected? (leave empty if unsure)

Data fetching (gS(S)P, getInitialProps), Dynamic imports (next/dynamic), Image optimization (next/image, next/legacy/image), SWC transpilation, Turbopack (--turbo)

Link to the code that reproduces this issue or a replay of the bug

https://gist.github.com/mkotsollaris/465bc28659c175c4aab10aeec984f739

To Reproduce

It happens sporadically, HMR enters into a certain loop that can't get out of, and this error is running again and again during next dev. This is my next.config.js:

const { AWS_ACCOUNT = 'development', GIT_BRANCH = 'master', CDN_PREFIX, NEXT_PUBLIC_ASSET_CDN_PREFIX } = process.env;
const assetPrefix = CDN_PREFIX || NEXT_PUBLIC_ASSET_CDN_PREFIX;

module.exports = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Strict-Transport-Security',
            value: 'max-age=63072000; includeSubDomains; preload',
          },
        ],
      },
    ];
  },
  swcMinify: true,
  experimental: {
    scrollRestoration: true,
  },
  reactStrictMode: true,
  images: {
    loader: 'custom',
  },
  publicRuntimeConfig: {
    awsAccount: AWS_ACCOUNT,
    appVersion: `${GIT_BRANCH}`,
    isDev: AWS_ACCOUNT === 'development',
    assetPrefix,
  },
  exportPathMap: () => ({}),
  assetPrefix,
};

Apologies, I don't have OSS code to share.

Describe the Bug

When running next dev, I occasionally enter a state where HMR keeps reloading and outputting DOMException: Failed to execute 'querySelectorAll' on 'Element': error. Once it enters that state, even a hard refresh won't be able to resolve it. Even when opening the window from a new browser (incognito etc.) I can see this error.

After the error shows up, I am unable to get out of the loop. I have to restart the server, and sometimes I have to do a fresh yarn install until it appears again.

Expected Behavior

I should be able to run next dev and HMR should be functioning without entering in a erroneous loop.

Which browser are you using? (if relevant)

Version 114.0.5735.198 (Official Build) (arm64)

How are you deploying your application? (if relevant)

next dev

[a6091731]

Hi @mkotsollaris My NextJs version is the same as yours. I encountered a similar problem to yours. Is there any suggested solution to provide? Thank you.

[iamnoufal]

Hi @mkotsollaris "Failed to execute 'querySelectorAll' on 'Element'" more likely because this method is called before DOM is initialized. You have to check if the "window" object is loaded before using "querySelectorAll" method

[padmaia]

@mkotsollaris can you try out v13.5+ and let me know if you are still experiencing this issue? 🙏

[mkotsollaris]

@padmaia I updated to the latest v13.5, and I am still able to reproduce this issue.

[tianbis]

Is there any news about this? I'm getting a similar error when next.js tries to show the error overlay, ending in an infinite loop.

[kimberlym4488]

We also are having this issue - the error overlay with next.js is simply an infinite loop. We can't access the initial error. Here are our versions:

Next.js - 14.0.3 Node - 20 npm - 10 React - 18.2 React-error-overlay - 6.0.11

[ForsakenHarmony]

Is this just happening with turbopack or next.js in general?

[kimberlym4488]

We are not using turbopack.

[psiie]

After some digging I found out what was causing the issue for us. (This issue lists the culprit as querySelectorAll, but ours is specifically querySelector. So It may not be the exact situation for everyone).

We are using a script from taga.adlightning.com on our site. This script seems to be monkeypatching document.querySelector without maintaining original behavior. I think they TRIED to do so by iinvoking the original function at the end of their shenanigans, but somewhere* in their code they return null early before invoking the original.

This is a problem because document.querySelector('html >>> :first-child') in react-dev-overlay relies on an exception throw to determine to NOT use deep picks. Deep picks no longer being in modern browsers (chrome at least) since late 2017 it seems.

Our solution looks to be to block the loading of this script in dev envronments. But its worth checking if your querySelectorAlls are native or overwritten. document.querySelectorAll.toString().

(*Their code is heavily obfuscated, not just minified)

[mkotsollaris]

After some digging I found out what was causing the issue for us. (This issue lists the culprit as querySelectorAll, but ours is specifically querySelector. So It may not be the exact situation for everyone).

We are using a script from taga.adlightning.com on our site. This script seems to be monkeypatching document.querySelector without maintaining original behavior. I think they TRIED to do so by iinvoking the original function at the end of their shenanigans, but somewhere* in their code they return null early before invoking the original.

This is a problem because document.querySelector('html >>> :first-child') in react-dev-overlay relies on an exception throw to determine to NOT use deep picks. Deep picks no longer being in modern browsers (chrome at least) since late 2017 it seems.

Our solution looks to be to block the loading of this script in dev envronments. But its worth checking if your querySelectorAlls are native or overwritten. document.querySelectorAll.toString().

(*Their code is heavily obfuscated, not just minified)

Great find @psiie . I was hoping that this would be fixed with dev-server in nextjs, so that we don't have to hack-around it. I suspect that this issue mostly happens during Google Tag Manager DOM ops, as you mentioned