Sentry Init failing in Chrome Extension Manifest V3

[abhishekops]

• 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.

[abhishekops]

Please find the following the initialization.

import * as Sentry from '@sentry/browser';
import { Integrations } from '@sentry/tracing';
(function () {
  try {
    Sentry.init({
      dsn: 'xxxxxx,
      integrations: [new Integrations.BrowserTracing()],
      tracesSampleRate: 1.0,
      release: 1.0,
    });
  } catch (e) {
    console.log('Error in Sentry init', e);
  }

I've removed the @sentry/tracing dependency, and the integrations from init, it seems to be working fine. But, I would love to use the tracing integration which has support for instrumentation. Please take a look. Thanks.

[onurtemizkan]

@abhishekops, thanks for reporting this. Could you provide a simple repro case (ideally a repo) for us to work on?

[abhishekops]

@onurtemizkan You may find the sample repo here. You can upload the build folder in the repo as an extension, you should see the error message once uploaded. The steps to upload are documented here. No changes required, you can upload the build folder directly. Let me know if you see any issues. Thanks.

[onurtemizkan]

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.

[abhishekops]

Thanks @onurtemizkan! I can confirm the work-around you suggested works in my case. As for the instrumentation, we can go the custom route for now. Though we would like the out of the box instrumentation, is there any plans to remove/bypass the window dependency in the coming releases? Thanks.

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[abhishekops]

@onurtemizkan Any update on the ETA for supporting this by default?

[mhkhansahab]

Hello there, I am using Manifest V3 and used this script that was shared by @abhishekops

  try {
    Sentry.init({
      dsn: 'xxxx',
      integrations: [new Integrations.BrowserTracing({
        routingInstrumentation: () => { },
      }),],
      tracesSampleRate: 1.0,
      release: 1.0,
    });
  } catch (e) {
    console.log('Error in Sentry init', e);
  }
})

try {
  Sentry.captureMessage("It's an error!")
} catch (e) {
  console.log(e);
}

But still I am not getting any log, is there any other solution to integrate Sentry with Manifest V3.

[JamesXiaoFF]

Did you find any solution? @mhkhansahab

[mhkhansahab]

Did you find any solution? @mhkhansahab

Yeah @JamesXiaoFF, I have found the solution.
I have used RavenJS for error logging of Service Worker, RavenJS is a Javascript SDK for Sentry. If you want to add Sentry on Service Worker(Background.js) use below snippet:

import Raven from 'raven-js';

Raven
  .config('Enter your DSN here')
  .install();
  
  try{
   //write something here
  }catch(err){
  Raven.captureException(err) //your captured error will be logged in Sentry
  }

In Content Script and PopupJS I used @sentry/browser, you can use below snippet:

import * as Sentry from "@sentry/browser";
import { BrowserTracing } from "@sentry/tracing";

Sentry.init({
  dsn: "Enter your DSN here",
  integrations: [new BrowserTracing()],
  tracesSampleRate: 1.0,
});

//write something here

[lforst]

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!

[Vadorequest]

I see v7.2 has been released 3 days ago, does that mean this fix has been released too?

Is there an up-to-date example on how to add Sentry for Chrome extension? I understand the main issue lies with the service worker (e.g: background.js), while the rest should work just fine.

[lforst]

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.

[Vadorequest]

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]

Well, it's still not working at all when importing @sentry/browser from a service worker file (e.g: background.js).

import * as Sentry from '@sentry/browser';

Uncaught TypeError: Cannot read properties of undefined (reading 'visibilityState')

var initHiddenTime = () => {
  return (0,_sentry_utils__WEBPACK_IMPORTED_MODULE_0__.getGlobalObject)().document.visibilityState === 'hidden' ? 0 : Infinity;
};

It crashes at the import level, because @sentry/browser relies on the document which doesn't exist in the context of a background script.

---

Edit: That's because I was loading BrowserTracing, when removing it it doesn't crash!

[lforst]

@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.