[BUG] Browser exceptions are no longer automatically tracked after 2.8.0

[WoodyWoodsta]

Description/Screenshot
Using 2.8.0, browser exceptions are no longer automatically caught and tracked. No error handler is present on the window.

Steps to Reproduce

1. Install 2.8.0 and throw an exception in the browser. Check Application Insights failures panel for errors. No exceptions are presented. No exceptions are added to the /track network request payload.
2. Install 2.7.4 and repeat. Exceptions are tracked, and the handler is present on the window.

• OS/Browser: MacOS/Chrome
• SDK Version: 2.8.0
• How you initialized the SDK:

export const appInsights = new ApplicationInsights({
  config: {
    instrumentationKey,
    extensions: [reactPlugin],
    enableDebug,
    loggingLevelConsole: enableDebug ? 2 : 0,
    loggingLevelTelemetry: enableDebug ? 2 : 1,
    autoTrackPageVisitTime: true,
    enableAutoRouteTracking: true,
    enableDebugExceptions: enableDebug,
    enableUnhandledPromiseRejectionTracking: true,
    enableCorsCorrelation: false,
    enableRequestHeaderTracking: true,
    enableResponseHeaderTracking: true,
  },
});

enableDebug=true

Expected behavior

As above, the exceptions thrown in the browser are tracked - the handler is present on the window.

[MSNev]

OK, the issue seems to be the way we are now hooking the window.onerror.
With a local repro I am getting the error events.

I'll restore to the "standard" method of hooking the onError rather than the monkey patching that 2.8.0 is currently using (this was done to support unloading)

[MSNev]

Actually it looks a little more nuanced as the hooking mechanism does assign the entry -- but, we also tag the endpoint that this is hooked -- so I suspect that part is causing the hook to fail sigh.

[WoodyWoodsta]

@MSNev Thank you for raising #1815 to fix this issue :)

[MSNev]

v2.8.1 is now fully deployed

[MSNev]

Rolled back CDN to v2.7.4 due to #1822

[MSNev]

On investigating #1822, while the fix for this issue doesn't throw anymore it also appears that it's still not correctly hooking the onerror function either

[WoodyWoodsta]

@MSNev Please let me know if there is anything I can do to help.

[MSNev]

I think, I've got it covered IE ends up throwing when the code attempts to set window.onerror because of the way it responds to the lookup code. Should have a PR published soon and then I'll publish a release

[MSNev]

v2.8.3 is now fully deployed to the CDN

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.