manipulating the Object.prototype may cause "malformed constraints object" TypeError in RTCPeerConnection constructor
Reported by
trve.t...@googlemail.com,
Aug 21
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0 Steps to reproduce the problem: 1. add a enumerable property to Object.prototype 2. create a new instance of RTCPeerConnection with a (valid) constraints object as the second parameter What is the expected behavior? it should successfully create the connection instance. What went wrong? it fails by throwing a TypeError: "TypeError: Failed to construct 'RTCPeerConnection': Malformed constraints object." Did this work before? N/A Does this work in other browsers? Yes Chrome version: 68.0.3440.106 (Official Build) (64-bit) (cohort: Stable) Channel: stable OS Version: 10.0 Flash Version: none I know that this second parameter with constraints is not in the spec (anymore - I guess?) [issue https://bugs.chromium.org/p/chromium/issues/detail?id=587563] and you already have an issue to deprecate and remove this parameter [issue https://bugs.chromium.org/p/chromium/issues/detail?id=576581]. But since this is still a thing and may cause totally unexpected issues in arbitrary websites that use WebRTC and do not update to the latest specs or libraries (as we currently probably do - sadly) I still report this here so you can do something about it. As mentioned, we (my comapany) uses Erizo by Lynckia (https://github.com/lynckia/licode), which still uses this constructor with the two parameters.
,
Aug 22
orphis@: Can you take a look?
,
Oct 15
:'(
,
Oct 15
We're manually parsing the second parameter as a dictionary. This is a non-standard parameter that we shouldn't take in in the first place, but for backwards compatibility if we do want to take it in, we should ignore any properties on it that is not recognized - we should not throw an exception like this.
,
Oct 15
|
||||
►
Sign in to add a comment |
||||
Comment 1 by guidou@chromium.org
, Aug 22