Description
Today, our globalHandlersIntegration monkey-patches window.onerror and window.onunhandledrejection directly. While this worked generally fine, it has the disadvantage that any party could come in with an improper monkey patch and remove Sentry form the listener chain.
Instead, we could use window.addEventListener('error') (same for unhanded rejection).
While we get the same data, this has the advantage that the SDK can't be removed by accident.
Compatibility-wise, using event handlers should be fine.
Which leaves us with the thing we need to investigate carefully: Compatibility with our loader script.
This is the reason why we currently still use onerror:
|
// Note: The reason we are doing window.onerror instead of window.addEventListener('error') |
|
// is that we are using this handler in the Loader Script, to handle buffered errors consistently |
However, we're not (yet) sure if this is actually a concern. Whatever we do here, we need to ensure that behaviour for the loader doesn't change and vice versa.
Description
Today, our
globalHandlersIntegrationmonkey-patcheswindow.onerrorandwindow.onunhandledrejectiondirectly. While this worked generally fine, it has the disadvantage that any party could come in with an improper monkey patch and remove Sentry form the listener chain.Instead, we could use
window.addEventListener('error')(same for unhanded rejection).While we get the same data, this has the advantage that the SDK can't be removed by accident.
Compatibility-wise, using event handlers should be fine.
Which leaves us with the thing we need to investigate carefully: Compatibility with our loader script.
This is the reason why we currently still use
onerror:sentry-javascript/packages/core/src/instrument/globalError.ts
Lines 22 to 23 in faada7c
However, we're not (yet) sure if this is actually a concern. Whatever we do here, we need to ensure that behaviour for the loader doesn't change and vice versa.