Skip to content

Cannot convert undefined or null to object in Chrome v74 #3388

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
5 tasks done
martinsaposnic opened this issue Apr 12, 2021 · 13 comments · Fixed by #4695
Closed
5 tasks done

Cannot convert undefined or null to object in Chrome v74 #3388

martinsaposnic opened this issue Apr 12, 2021 · 13 comments · Fixed by #4695

Comments

@martinsaposnic
Copy link

https://sentry.io/organizations/the-dotcom-u0/issues/2334549076/?project=1880120&query=is%3Aunresolved

Package + Version

  • @sentry/browser

Version:

6.2.5

Description

Happening in Chrome version 74.0.3729.0

Getting this error: Cannot convert undefined or null to object

image

image

It seems that this issue should be reopened #2074 and this PR #3208 doesn't solve this issue

@kamilogorek
Copy link
Contributor

This is indicated as the error coming from the Sentry, as we are wrapping rAF API to get some useful data (eg. function name, but in your case, it's not helpful, as you are using anonymous callbacks).

The error is produced when calling the original requestAnimationFrame handler, which means that it comes from decorateHandler, wait-for or detectElementResize. I'd first check detectElementResize, as it's easy to lose a reference to dom element/object when you are not cleaning up rAF calls.

This error is usually produced by Object.keys or Object.assign calls.

Hope that helps to dig into the issue more. Cheers!

@iulo
Copy link

iulo commented Apr 20, 2021

@kamilogorek Hi bro, does this issue is same as #2074 ?

I saw @martinsaposnic use v6.2.5, but still got this error.

And @NateScarlet reference a link which provide a solution, is it appropriate ?

const isAffectByIssue3388 = navigator.userAgent.includes('Chrome/74.0.3729')
new sentry.Integrations.TryCatch({
   requestAnimationFrame: !isAffectByIssue3388,
}),

@kamilogorek
Copy link
Contributor

kamilogorek commented Apr 20, 2021

Yes, this would be correct:

const isAffectByIssue3388 = navigator.userAgent.includes('Chrome/74.0.3729')
Sentry.init({
  integrations: [new Sentry.Integrations.TryCatch({
   requestAnimationFrame: !isAffectByIssue3388,
  })]
});

@iulo
Copy link

iulo commented Apr 20, 2021

Tks bro. I use this, should have better compatibility, no need rewrite all default integrations

const isAffectByIssue3388 = navigator.userAgent.includes('Chrome/74.0.3729')

Sentry.init({
  integrations: function(integrations) {
    const newIntegrations = integrations.map((integration) => {
      if (integration.name === 'TryCatch') {
        return new Sentry.Integrations.TryCatch({
          requestAnimationFrame: !isAffectByIssue3388 // disable raf hook
        })
      }

      return integration
    })
    return newIntegrations
  }
})

@kamilogorek
Copy link
Contributor

It won't rewrite them. We are doing a smart-merge, so only TryCatch will be overritten. My code is effectively the same as yours :)

@iulo
Copy link

iulo commented Apr 20, 2021

Oh ok, thanks for providing this info

@NateScarlet
Copy link

event target wrap is also affected, is this same as #2074 ?

image

@kamilogorek
Copy link
Contributor

Every instrumentation that eventually calls native function can be reported like this. It's very rare occurrence, but it can happen.

@Fonger
Copy link

Fonger commented May 24, 2021

We have the same issues. However, not everyone uses chrome 74.0.3729. Some android app (like Facebook) is using their own Facebook user-agent, but the underlying browser is system webview, which may be chrome 74. We can't fully apply workaround for these users by detecting user-agent. Hope this can be fixed.

@qtiki
Copy link

qtiki commented Aug 31, 2021

We're also seeing this. Are there plans to implement the proposed workaround in Sentry SDK or does everybody need to copy&paste the fix from here?

@chuanxiaojin
Copy link

We have the same issues. However, not everyone uses chrome 74.0.3729. Some android app (like Facebook) is using their own Facebook user-agent, but the underlying browser is system webview, which may be chrome 74. We can't fully apply workaround for these users by detecting user-agent. Hope this can be fixed.

@Fonger hello, How did you finally solve it?

@Fonger
Copy link

Fonger commented Nov 5, 2021

We have the same issues. However, not everyone uses chrome 74.0.3729. Some android app (like Facebook) is using their own Facebook user-agent, but the underlying browser is system webview, which may be chrome 74. We can't fully apply workaround for these users by detecting user-agent. Hope this can be fixed.

@Fonger hello, How did you finally solve it?

Sadly we didn't solve it. I just apply the Chrome 74 user-agent workaround and ignore the minority of the affected users.

@chuanxiaojin
Copy link

We have the same issues. However, not everyone uses chrome 74.0.3729. Some android app (like Facebook) is using their own Facebook user-agent, but the underlying browser is system webview, which may be chrome 74. We can't fully apply workaround for these users by detecting user-agent. Hope this can be fixed.

@Fonger hello, How did you finally solve it?

Sadly we didn't solve it. I just apply the Chrome 74 user-agent workaround and ignore the minority of the affected users.

ok, thanks.

lobsterkatie added a commit that referenced this issue Mar 8, 2022
…on (#4695)

Users have reported running into a bug in Chrome wherein calling `addEventListener` or `requestAnimationFrame` too many times on `window` eventually throws an error when our `try-catch` integration is running, specifically because of how we wrap those functions. In the discussion of that bug, [one user](#2074 (comment)) reported that replacing our `call` call with an `apply` call in our wrapping functions solved the problem for him.

This makes that change, in the hopes it will fix the problem for everyone.

Fixes #3388
Fixes #2074
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants