Disabling IPC protocol with build flags?
TL;DR: Is there a way to make a "manages" declaration conditional, for protocols that depend on types that might not be defined for certain build-flags? I ask because I am working on a protocol that fulfills webrtc's networking needs (PMediaTransport), but webrtc can be disabled as a whole with the --disable-webrtc build flag. PMediaTransport uses many types that aren't defined when webrtc is disabled. I have tried the following approaches so far: 1. Export a mostly-empty dummy version of PMediaTransport instead of the real one when webrtc is disabled. This gets me an "error: |manager| declaration in protocol `PMediaTransport' does not match any |manages| declaration in protocol `PSocketProcessBridge'", even after a clobber. If I remove the "real" PMediaTransport from the tree, this approach works. It seems that ipdl files are processed in-tree (at least partially) instead of in exports. 2. Make sure the types PMediaTransport depends on are always defined. This ends up pulling in a ton more webrtc-only code that these types depend on, which is not ideal. The next thing for me to try is to typedef all of these undefined types to int or similar when webrtc is disabled, but I was wondering if there was a way to make a "manages" conditional on build-flags? Best regards, Byron Campen ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: RTCRtpSender.getParameters() and RTCRtpSender.setParameters()
Firefox currently supports an old version of RTCRtpSender.getParameters() and RTCRtpSender.setParameters(), which has changed significantly in more recent versions of the webrtc-pc spec. The most important change is the introduction of a transaction model, wherein setParameters() can only be called with the results of the most recent getParameters() call, with the desired modifications. This change is not backward compatible with the present implementation, because the webrtc-pc spec has changed in a non-backward-compatible way. It is likely that existing code using RTCRtpSender.setParameters() will need to be updated to work with the new version of this API. Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1534687 https://bugzilla.mozilla.org/show_bug.cgi?id=1401592 https://bugzilla.mozilla.org/show_bug.cgi?id=1531458 Standard: https://w3c.github.io/webrtc-pc/ Testing: testing/web-platform/tests/webrtc/RTCRtpParameters-* testing/web-platform/tests/webrtc/RTCRtpSender-setParameters.html testing/web-platform/tests/webrtc/protocol/video-codecs.https.html dom/media/tests/mochitest/test_peerConnection_setParameters.html Cross-browser support: Chrome (and Edge) supports the more recent version of this API. Safari appears to have partial support for this API, but does not pass the relevant web-platform-tests. Platform coverage: All Target release: 78 Preferences behind which this will be implemented: None ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement and ship: RTCRtpReceiver.getParameters()
Firefox currently has no support for RTCRtpReceiver.getParameters(). Bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1618999 Standard: https://w3c.github.io/webrtc-pc/ Testing: testing/web-platform/tests/webrtc/RTCRtpReceiver-getParameters.html Cross-browser support: Chrome (and Edge) appear to have basic support for this API, although the simulcast web-platform-test does not currently pass. Platform coverage: All Target release: 78 Preferences behind which this will be implemented: None ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
