deadbeef@ already identified where this happens: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/modules/mediastream/RTCPeerConnection.cpp?sq=package:chromium&rcl=1465557519&l=144

Yup, the old Dictionary-parsed-in-C++ calls supported these nonstandard (no-longer-standard) features, while the new IDL-based dictionary parser doesn't.

The fix is fairly trivial (mangle in https://codesearch.chromium.org/chromium/src/third_party/WebKit/Source/modules/mediastream/RTCOfferAnswerOptions.idl?dr=C&q=RTCOfferAnswerOptions.idl&sq=package:chromium&l=1) , the only question is how much pushback we get on adding non-standard options to the Web-exposed API.

I know that these two options got deprecated in latest draft versions in favor of using addTransceiver(), but since it seems that the new API is not yet implemented in Chrome, doesn't it make sense to continue supporting them? At least, until the transition could be made without breaking any clients or losing functionality.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/b0e609db70af6bab30628e7bf14ad6a8add1a40e

commit b0e609db70af6bab30628e7bf14ad6a8add1a40e
Author: guidou <guidou@chromium.org>
Date: Tue Jun 21 09:13:15 2016

Support legacy offerToReceiveAudio/offerToReceiveVideo fields in RTCOfferOptions.

BUG= 619289 

Review-Url: https://codereview.chromium.org/2077323003
Cr-Commit-Position: refs/heads/master@{#400927}

[modify] https://crrev.com/b0e609db70af6bab30628e7bf14ad6a8add1a40e/components/test_runner/mock_webrtc_peer_connection_handler.cc
[modify] https://crrev.com/b0e609db70af6bab30628e7bf14ad6a8add1a40e/third_party/WebKit/LayoutTests/fast/mediastream/RTCPeerConnection-createOffer-expected.txt
[modify] https://crrev.com/b0e609db70af6bab30628e7bf14ad6a8add1a40e/third_party/WebKit/LayoutTests/fast/mediastream/RTCPeerConnection-createOffer-promise.html
[modify] https://crrev.com/b0e609db70af6bab30628e7bf14ad6a8add1a40e/third_party/WebKit/LayoutTests/fast/mediastream/RTCPeerConnection-createOffer.html
[modify] https://crrev.com/b0e609db70af6bab30628e7bf14ad6a8add1a40e/third_party/WebKit/Source/modules/mediastream/RTCOfferOptions.idl
[modify] https://crrev.com/b0e609db70af6bab30628e7bf14ad6a8add1a40e/third_party/WebKit/Source/modules/mediastream/RTCPeerConnection.cpp

guidou@, can this be tested manually so that we can verify it on Canary before the CL gets merged in to M52 branch ?

#9: if this works then the output of 
  var pc = new webkitRTCPeerConnection(null);
  pc.createOffer({offerToReceiveAudio: 1})
  .then(function(offer) { console.log(offer.sdp); })
should be roughly identical to te output of
  var pc = new webkitRTCPeerConnection(null);
  pc.createOffer(function(offer) { console.log(offer.sdp); }, console.error, 
    {offerToReceiveAudio: 1});
in terms of length and presence of a line that starts with m=audio.

Your change meets the bar and is auto-approved for M52 (branch: 2743)

Perhaps the Promise based overloads should just be unshipped instead, until the rest of the API (only the parts that replace the offerToReceiveAudio and friends) is ready?

What does Firefox do?

Firefox supports offerToReceive*.

Sounds like the new old standard.

WebKit also supports offerToReceive* on the promise-based overloads.
https://trac.webkit.org/browser/trunk/Source/WebCore/Modules/mediastream/RTCOfferAnswerOptions.cpp?rev=202109

Yes, I was just about to check WebKit. You saved me some time. :)
It also seems to support addTrasceiver.

I hardly believe offerToReceive* will ever go away, then.

The spec issue about restoring these fields is here:

https://github.com/w3c/webrtc-pc/issues/709

#9: A sample page that runs fippo's proposed test is available at
https://guidou.github.io/createoffer1.html

Rechecked this on chrome canary version 53.0.2777.0 on Windows, MAC and Ubuntu 14.04. as per the comment#10, when executed both the scrips in dev console gave the same output as

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126

Also executed the same test case as in comment#19, both promise based and call back based createoffer() method returned the same output:

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 126

Fix is working as intended. Adding TE-Verified labels.

Thanks.!

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9e4c3ebd35922fee6573e921e629cb7faa251b91

commit 9e4c3ebd35922fee6573e921e629cb7faa251b91
Author: Guido Urdaneta <guidou@chromium.org>
Date: Fri Jun 24 11:14:58 2016

Support legacy offerToReceiveAudio/offerToReceiveVideo fields in RTCOfferOptions.

BUG= 619289 

Review-Url: https://codereview.chromium.org/2077323003
Cr-Commit-Position: refs/heads/master@{#400927}
(cherry picked from commit b0e609db70af6bab30628e7bf14ad6a8add1a40e)

Review URL: https://codereview.chromium.org/2097683003 .

Cr-Commit-Position: refs/branch-heads/2743@{#464}
Cr-Branched-From: 2b3ae3b8090361f8af5a611712fc1a5ab2de53cb-refs/heads/master@{#394939}

[modify] https://crrev.com/9e4c3ebd35922fee6573e921e629cb7faa251b91/components/test_runner/mock_webrtc_peer_connection_handler.cc
[modify] https://crrev.com/9e4c3ebd35922fee6573e921e629cb7faa251b91/third_party/WebKit/LayoutTests/fast/mediastream/RTCPeerConnection-createOffer-expected.txt
[modify] https://crrev.com/9e4c3ebd35922fee6573e921e629cb7faa251b91/third_party/WebKit/LayoutTests/fast/mediastream/RTCPeerConnection-createOffer-promise.html
[modify] https://crrev.com/9e4c3ebd35922fee6573e921e629cb7faa251b91/third_party/WebKit/LayoutTests/fast/mediastream/RTCPeerConnection-createOffer.html
[modify] https://crrev.com/9e4c3ebd35922fee6573e921e629cb7faa251b91/third_party/WebKit/Source/modules/mediastream/RTCOfferOptions.idl
[modify] https://crrev.com/9e4c3ebd35922fee6573e921e629cb7faa251b91/third_party/WebKit/Source/modules/mediastream/RTCPeerConnection.cpp