Skip to content

Sentry v8 broke the integration with our Chrome extension which uses Vue. #12025

Closed

Description

@pavitra-infocusp

Is there an existing issue for this?

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/vue

SDK Version

8.0.0

Framework Version

3.4.21

Link to Sentry event

No response

SDK Setup

import { BrowserClient, Scope, browserTracingIntegration, defaultStackParser, makeFetchTransport, replayIntegration, vueIntegration } from "@sentry/vue";
import packageJson from '../package.json';

export function initSentry(app, router) {
  const client = new BrowserClient({
    dsn: "https://________@________.ingest.sentry.io/________",
    transport: makeFetchTransport,
    stackParser: defaultStackParser,
    integrations: [
      browserTracingIntegration({ router }),
      // replayIntegration({
      //   maskAllText: false,
      //   blockAllMedia: false,
      // }),
      vueIntegration({ app, trackComponents: true }),
    ],
    // Set 'tracePropagationTargets' to control for which URLs distributed tracing should be enabled
    tracePropagationTargets: ["localhost", "https://api.example.com"],
    // Performance Monitoring
    tracesSampleRate: 1.0, //  Capture 100% of the transactions
    // Session Replay
    // Capture Replay for 10% of all sessions,
    // plus for 100% of sessions with an error
    replaysSessionSampleRate: 0.1,
    replaysOnErrorSampleRate: 1.0,

    environment: import.meta.env.MODE,
    release: `my-extension@${packageJson.version}`
  });

  const scope = new Scope();
  scope.setClient(client);

  client.init();
}

Steps to Reproduce

I just upgraded to v8 of the Sentry JS SDK, and it said that browser extension can't use global init. So, I changed my code to use scope init as above.

Expected Result

It should catch any errors without any setup other than initing the SDK.

Actual Result

I am disappointed that it does not track any errors by itself. Explicit calls using scope.captureException works, but this is undesirable.

Activity

  1. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on May 14, 2024
  2. pavitra-infocusp commented on May 14, 2024

    @pavitra-infocusp
    Author

    Cause: #10632

  3. pavitra-infocusp commented on May 14, 2024

    @pavitra-infocusp
    Author

    Our Chrome extension runs on only on the new tab page. I couldn't understand the reasoning behind disabling extensions support completely, instead of finding alternative solutions.

  4. Lms24 commented on May 14, 2024

    @Lms24
    Member

    Hi @pavitra-infocusp thanks for writing in! This was an intentional change and we're likely not going to revert it.
    Using Sentry in a browser extension is quite an edge case and I'd argue it's in everyones best interest if chrome extensions do not capture errors and data from the host websites and vice versa. This was our main motivation for "disabling" the Sentry.init call and adding a specific guide how to use Sentry in browser extensions.

    I couldn't understand the reasoning behind disabling extensions support completely, instead of finding alternative solutions.

    Unfortunetely, there's no good way to isolate extensions from the rest of the page (and vice versa). If you have concrete suggestions, feel free to let us know.

    Our Chrome extension runs on only on the new tab page

    In this case, if you can ensure that your extension really runs in "empty" tabs, you can re-add the global integrations that we're filtering out in this guide. Ultimately this will give you the same experience as previously with a simple Sentry.init call.

  5. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on May 14, 2024
  6. pavitra-infocusp commented on May 14, 2024

    @pavitra-infocusp
    Author

    The document https://docs.sentry.io/platforms/javascript/best-practices/browser-extensions/ provides no help with setting up the error handling instrumentation code manually. It leaves us with zero clue how to use Sentry further.

  7. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on May 14, 2024
  8. Lms24 commented on May 14, 2024

    @Lms24
    Member

    It leaves us with zero clue how to use Sentry further.

    The usual way of using Sentry "manually" is to try/catch your application's code and send the error to Sentry using captureException. This is documented and should always work.

    In your specific case you're already adding vueIntegration to your client setup which will register a Vue errorHandler. So errors caught from Vue should be sent automatically to Sentry.

  9. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on May 14, 2024
  10. pavitra-infocusp commented on May 14, 2024

    @pavitra-infocusp
    Author

    Thanks for the help @Lms24! I have figured out to brute force my way in.

  11. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on May 14, 2024
  12. yhuang1211 commented on May 15, 2024

    @yhuang1211

    I'm using react in my Extension and having a similar problem. I thought an extension Popup is totally isolated from the web page so it might be ok to use Sentry.init there? Only Content Script should be restricted using the scope described in https://docs.sentry.io/platforms/javascript/best-practices/browser-extensions/

  13. Lms24 commented on May 15, 2024

    @Lms24
    Member

    @yhuang1211 I'm not sure if a popup is actually isolated. If you documentation to back this up we could think about adding a sentence in docs about it. Basically what we need is that globalThis/window/document are not the same "instances" if you will, as the ones on the currently open website.

    Also, would there be a possibility for an SDK like ours to check if an extension is only running in a (maybe) isolated popup vs. actually interfering with/accessing the host website?

    If not, I don't think we'll revisit this decision. We appreciate and are aware that folks use Sentry in chrome extensions but this is just not a use case we can support with as much ease as when adding Sentry to a web app/page. I hope I outlined our reasoning well in this thread and in the documentation

  14. saranya-sivan commented on May 20, 2024

    @saranya-sivan

    @Lms24
    We understand the reasoning behind Sentry.init() being restricted for content scripts which are injected to the websites. But, say if we are using Sentry from the extension background script (service worker scope), this restriction to browser client may not be required as it is already isolated. However, we receive this error in the background scripts of extensions as well.

    With browserClient setup, integrations doesn't work as expected by default.
    By using setCurrentClient to bind to global scope the integrations worked. Can you please suggest on if this the right approach? Couldn't find much on the documentation on integrations.

    const client = new BrowserClient({
      dsn: ‘DSN’,
      transport: makeFetchTransport,
      stackParser: defaultStackParser,
      integrations: [captureConsoleIntegration({levels: ['error', 'warn']})],
    });
    const scope = new Scope();
    scope.setClient(client);
    client.init(); 
    **Sentry.setCurrentClient(client);**
  15. Lms24 commented on May 21, 2024

    @Lms24
    Member

    However, we receive this error in the background scripts of extensions as well

    I assume with "this error" you mean the message that the SDK will not initialize in a browser extension via Sentry.init?

    This is most likely the case because our check for if the SDK is initialized in an extensions returns true. If you have a suggestion how we could correctly detect a background script of a chrome extension, we can exclude this case.

    With browserClient setup, integrations doesn't work as expected by default.

    I obviously can't force you to do anything but I'd strongly recommend to not use captureConsoleIntegration in your extension. Browser console is global, just like window or globalThis. So using it has the same implications as globalHandlersIntegration or browserApiErrorsIntegration - stuff from the host website will leak into your Sentry project and potentially vice versa.

    Also, using Sentry.setCurrentClient is heavily discouraged because it will set your Sentry client and scope as the global one. Again opening your app as well as the host app up to data leakage.


    To sum this up, I would like to point out that to the best of our knowledge, running Sentry in a browser extension is more an edge case than the norm. As such, for the reasons I stated above and in our docs, affected users will have to add a slightly more complicated version of initializing the SDK. As long as browsers don't give us better context isolation there's no way around this.

  16. Thomas101 commented on May 21, 2024

    @Thomas101

    I have to admit, this has tripped us up during the upgrade too and trying to figure out what to do for best has taken quite a bit of time! I completely get what you're trying to do here and it makes a lot of sense when you're running in a semi-shared world like a contentscript. We had trouble getting Sentry to work in our service worker and also on dedicated extension pages that we're hosting, where we are the only code that's running and are 100% sure of this.

    The extra setup is not a problem, but in our instance, on these dedicated extension pages, we wanted to capture all errors and unhandled rejections for reporting like in v7. The first thing we tried, was just not filtering the integrations as suggested in the guide but the errors were not reported. We bound on the window unhandledrejection and error events, then used scope.captureException but found the stack traces weren't always great (probably something we've done wrong).

    As @saranya-sivan suggested, using Sentry.setCurrentClient(client) in these dedicated pages restores the old behaviour, which is what we want (of course with caveats that you mentioned).

    I think there's definitely a strong use case for still reporting all errors in the environments where it makes sense. Would it be possible to update the docs so that the extension use-case is split into two (i.e. content script & dedicated page) so it doesn't trip as many people up in the future? Or you might be able to check if you're running in a dedicated extension page with something like...

    const isDedicatedExtensionPage = (
      chrome.runtime &&
      window === window.top &&
      window.location.href.startsWith(`chrome-extension://${chrome.runtime.id}`)
    )

    ...and then continue the init, maybe with a warning rather stopping the initialization?

  17. Lms24 commented on May 21, 2024

    @Lms24
    Member

    Hey @Thomas101 thanks for sharing your thoughts and for the code to check for a dedicated page!

    I opened #12156 which incorporates your suggestion. Also, highlighting the different types of chrome extensions might be useful in the docs. I was planning on adding 1-2 sentences to the browser extension guide anyway so I might as well do this.

    I guess we're not gonna get into a perfect state here, because we essentially have to opt-out certain cases within browser extensions just like the dedicated pages but let's try to improve things as much as we can 🤞

  18. bskdany commented on May 30, 2025

    @bskdany

    @Lms24 hijacking this old threadto st ay on topic, would the standard approach of sentry.init be just fine for a chrome extension without any content scripts? Just popup and background

  19. Lms24 commented on May 30, 2025

    @Lms24
    Member

    @bskdany just to clarify

    Just popup and background

    you mean an extra window/panel that opens when you click the extension icon, right? Yes that should be fine!

  20. ghost added on Aug 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions