This uses addEventListener instead of window.onerror to set the handler for the loader.
This way, we avoid infinite recursion when users also do that, e.g. right after loading the loader:

const oldOnError = window.onerror;

window.onerror = function () {
  console.log('custom error');
  oldOnError && oldOnError.apply(this, arguments);
};

window.doSomethingWrong();

Rundown of the problem:

The root cause for this issue was this new check we added:
https://github.com/getsentry/sentry/pull/47311/files#diff-02afb4c480e9e9c8bcc2f5fd8096291fd71d113cc2d50139624c6d890fed6e88L54

So where did this cause issues?
Imagine following setup and order of users' Website

-> Loader script
-> Other script that overwrites window.onError
-> throw an unhandled Error

What was happening is that because of the if

if (_window[_onerror] && _window[_onerror].__SENTRY_LOADER__) {
    _window[_onerror] = _oldOnerror;
}

this is invoked whenever we the full SDK was loaded but not initialized yet.

Previously it was this:

_window[_onerror] = _oldOnerror;

Since initially window.onError is null we caused an endless loop of re-calling the Loader onError

_window[_onerror] = function () {
    queue({
        e: [].slice.call(arguments),
    });
    if (_oldOnerror) {
        _oldOnerror.apply(_window, arguments);
    }
};

on the other, the external onError handler, caused the site to slowly run out of memory.
Now we use event listeners instead to not have to deal with overwriting onError.

In the old version where we still dealt with onError callback - we also caused a bug where we set the handler back to null regardless if a second one was registered in the meantime.