sentry-javascript: Sentry Init failing in Chrome Extension Manifest V3

Review the documentation: https://docs.sentry.io/
Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
Use the latest release: https://github.com/getsentry/sentry-javascript/releases
Provide a link to the affected event from your Sentry account

Package + Version

@sentry/browser
@sentry/node
raven-js
raven-node (raven for node)
other:

Version:

6.13.3

Description

Apologies if this was asked previously. I’m trying to integrate Sentry into background scripts of Chrome Extension manifest V3. Sentry Initi fails with the following trace, upon digging into it, the exact line where it fails is https://imgur.com/a/UAGs5QR

Actual error trace:

Error in Sentry init TypeError: Cannot read properties of undefined (reading 'querySelector')
    at y (background.bundle.js:118)
    at g (background.bundle.js:118)
    at e._createRouteTransaction (background.bundle.js:118)
    at background.bundle.js:118
    at a (background.bundle.js:127)
    at e.setupOnce (background.bundle.js:118)
    at l (background.bundle.js:79)
    at background.bundle.js:79
    at Array.forEach (<anonymous>)
    at d (background.bundle.js:79)
    at t.setupIntegrations (background.bundle.js:76)
    at e.bindClient (background.bundle.js:103)
    at o (background.bundle.js:94)
    at Module.S (background.bundle.js:46)
    at background.bundle.js:307
    at background.bundle.js:307
    at background.bundle.js:307
    at background.bundle.js:307

This is expected to fail as the manifest V3 version of Chrome Extension background scripts don’t have access to DOM, and they are run as service workers, which explains the issue. I would like to know if there is a way to integrate Sentry where window/document objects aren’t present. Its really critical for us to integrate Sentry into the background scripts, as most of the important action happens there. Kindly assist if there is a solution or any workarounds for the problem. Thanks in advance.

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 3
Comments: 16 (4 by maintainers)

Most upvoted comments

Thanks for the feedback, I believe a “safe” example dedicated to extensions should come to light then, especially since it’s not straightforward to configure it properly.

Vadorequest on Jun 20, 2022

@Vadorequest sorry about that. I created a follow-up issue with the bug you described instead of reopening this one, because the bug is a different one.

For the time being, I recommend chrome extension authors not to use the tracing package.

lforst on Jun 21, 2022

Yes, this should be fixed with v7.

We do not yet have an up-to-date example on how to set up Sentry with Chrome extensions. For transparency reasons I should also mention that chrome extensions are currently not really on our radar. We try to keep the SDK compatible with extensions, but it’s not something we explicitly test for. Most of the time the @sentry/browser extension should work fine for most use cases - let us know when this is not the case and we’ll try to resolve it.

Side-note to extension authors: Injecting the Sentry SDK on arbitrary pages is highly discouraged. Injected Sentry SDKs might clash with a Sentry SDK already running on a page. Not only will this mean that the SDK you injected most likely won’t work, but also you break the SDK the website is already running - ruining fun for everyone.

lforst on Jun 20, 2022

Hi, Raven.js is a very old version of our Sentry SDK and using it is discouraged! I just merged a PR that should fix this issue. We will have a release candidate for our upcoming v7 version soon. Please try it out and report back whether the fix resolved your issue!

lforst on May 24, 2022

Thanks for the repo @abhishekops. Currently, the default routingInstrumentation of BrowserTracing plugin needs to access the window. As a workaround, you can bypass routingInstrumentation as below:

integrations: [
  new Integrations.BrowserTracing({
    routingInstrumentation: () => {},
  }),
],

Also, you can manually trace the critical parts of your background scripts. I can confirm that using custom performance instrumentation works for your case. Please let me know if this helps.

onurtemizkan on Nov 6, 2021