wrapPeerConnectionEvent crashes application when addEventListener is non-writable

[kalvin807]

Please read first!

Please use discuss-webrtc for general technical discussions and questions.

• I have provided steps to reproduce (e.g. a link to a jsfiddle)
• I have provided browser name, version and adapter.js version
• This issue only happens when adapter.js is used

Note: If the checkboxes above are not checked (which you do after the issue is posted), the issue will be closed.

Versions affected

Browser name including version (e.g. Chrome 64.0.3282.119)
Any browser I believes, as long as it is a wix site (I reproduced with firefox/chrome/safari)

adapter.js (e.g. 6.1.0)
9.0.4

Description

wrapPeerConnectionEvent in src/js/utils.js crashes when EventTarget.prototype.addEventListener is made non-writable by the host environment (e.g. Wix's site). Since adapterFactory() runs all shims immediately on import, this crashes the application at load time if they import this package.

We are currently have a working around by patching with a try-catch guard before the assignment

const nativeAddEventListener = proto.addEventListener;
try { proto.addEventListener = nativeAddEventListener; }
catch (e) { return; }

• related downstream issue livekit/client-sdk-js#1806

Steps to reproduce

1. Open DevTools console on any page
2. Go to one of the wix's example site (https://www.wix.com/explore/websites)
3. Load adapter.js:

  var s = document.createElement('script');
  s.src = 'https://unpkg.com/webrtc-adapter@9.0.4/out/adapter.js';
  document.head.appendChild(s);
  // → TypeError: Cannot assign to read only property 'addEventListener'

Expected results

adapter.js loads without error, gracefully skipping patches it cannot apply.

Actual results

TypeError: Cannot assign to read only property 'addEventListener' of object '#'
Crashes at module initialization, prevents any library that bundles adapter.js from loading.

[fippo]

From inserting a

Object.defineProperty(EventTarget.prototype, 'addEventListener', {
    writable: false
 });

into the test page it looks like this happens in three places:

• Chrome shim's shimOnTrack which should probably not attempt to do anything in versions that unshipped plan-b (M102)
• Chrome shim's fixNegotiationNeeded which also shouldn't attempt to fix things in M102+
• The common shim's shimSendThrowTypeError. Originally built for Firefox 57 and fixed in FF60.

That shim is still required in Chrome 145+ and probably Safari, I filed https://issues.chromium.org/issues/490588131

[fippo]

Should no longer happen in v9.0.5