You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Sentry v8 broke the integration with our Chrome extension which uses Vue. #12025
import{BrowserClient,Scope,browserTracingIntegration,defaultStackParser,makeFetchTransport,replayIntegration,vueIntegration}from"@sentry/vue";importpackageJsonfrom'../package.json';exportfunctioninitSentry(app,router){constclient=newBrowserClient({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 enabledtracePropagationTargets: ["localhost","https://api.example.com"],// Performance MonitoringtracesSampleRate: 1.0,// Capture 100% of the transactions// Session Replay// Capture Replay for 10% of all sessions,// plus for 100% of sessions with an errorreplaysSessionSampleRate: 0.1,replaysOnErrorSampleRate: 1.0,environment: import.meta.env.MODE,release: `my-extension@${packageJson.version}`});constscope=newScope();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.
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.
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.
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.
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/
@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
@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.
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.
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...
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 🤞
@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
Activity
pavitra-infocusp commentedon May 14, 2024
Cause: #10632
pavitra-infocusp commentedon May 14, 2024
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.
Lms24 commentedon May 14, 2024
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.initcall and adding a specific guide how to use Sentry in browser extensions.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.
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.initcall.pavitra-infocusp commentedon May 14, 2024
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.
Lms24 commentedon May 14, 2024
The usual way of using Sentry "manually" is to
try/catchyour application's code and send the error to Sentry usingcaptureException. This is documented and should always work.In your specific case you're already adding
vueIntegrationto your client setup which will register a Vue errorHandler. So errors caught from Vue should be sent automatically to Sentry.pavitra-infocusp commentedon May 14, 2024
Thanks for the help @Lms24! I have figured out to brute force my way in.
yhuang1211 commentedon May 15, 2024
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/
Lms24 commentedon May 15, 2024
@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/documentare 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
saranya-sivan commentedon May 20, 2024
@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.
Lms24 commentedon May 21, 2024
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.
I obviously can't force you to do anything but I'd strongly recommend to not use
captureConsoleIntegrationin your extension. Browser console is global, just likewindoworglobalThis. So using it has the same implications asglobalHandlersIntegrationorbrowserApiErrorsIntegration- stuff from the host website will leak into your Sentry project and potentially vice versa.Also, using
Sentry.setCurrentClientis 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.
Thomas101 commentedon May 21, 2024
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
unhandledrejectionanderrorevents, then usedscope.captureExceptionbut 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...
...and then continue the init, maybe with a warning rather stopping the initialization?
Lms24 commentedon May 21, 2024
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 🤞
bskdany commentedon May 30, 2025
@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
Lms24 commentedon May 30, 2025
@bskdany just to clarify
you mean an extra window/panel that opens when you click the extension icon, right? Yes that should be fine!