Revision 8f1ef70886a1443ccd9980448031c88a44c3faea authored by Ben Pastene on 13 April 2018, 17:03:33 UTC, committed by Chromium WPT Sync on 13 April 2018, 17:03:33 UTC
This reverts commit 7c3d1d13f940e88ef6706fd8b5c257a81d340ed9.
Reason for revert: WebviewLoginTest.Basic is still flaky on linux-chromeos-rel
https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-rel/6886
https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-rel/6887
Original change's description:
> Reland: Use PostTask to schedule cross-process postMessage forwarding.
>
> Changes from original attempt at https://crrev.com/c/999182:
> - fix flakiness in two additional ChromeOS login tests
> - fix CSP WPT tests to not depend on ordering between iframe's onload
> and postMessage - see https://crbug.com/832319.
>
> Previously, we sent the IPC to forward a cross-process postMessage
> immediately. This caused a behavioral difference from the
> same-process case where the postMessage is always scheduled. Namely,
> in a scenario like this:
>
> frame.postMessage(...);
> doSomethingThatSendsIPCsToFrame(frame);
>
> the IPCs from JS following the postMessage would've been ordered
> incorrectly, causing |frame| to see their side effects after the
> postMessage dispatch in the cross-process case, whereas they would be
> seen before the postMessage dispatch in the same-process case. One
> example of this is frame.focus(), and another is a frame element
> onload event (dispatched via FrameHostMsg_DispatchLoad) arriving after
> a postMessage dispatched from an inline script while the frame was
> still loading.
>
> To resolve these ordering concerns, this CL changes cross-process
> postMessage to do a PostTask on the sender side before sending the
> message to the browser process. This improves the current state of
> the world, but does not yet achieve a perfect match for the IPC
> ordering in the same-process case - see discussion on the bug.
>
> Bug: 828529
> Change-Id: I62a627c501526d09900be4f5bd2c899acf4d1e07
> Reviewed-on: https://chromium-review.googlesource.com/999182
> Reviewed-by: Xiyuan Xia <xiyuan@chromium.org>
> Reviewed-by: Daniel Cheng <dcheng@chromium.org>
> Commit-Queue: Alex Moshchuk <alexmos@chromium.org>
> Cr-Original-Commit-Position: refs/heads/master@{#550284}
> Reviewed-on: https://chromium-review.googlesource.com/1011287
> Cr-Commit-Position: refs/heads/master@{#550621}
TBR=xiyuan@chromium.org,dcheng@chromium.org,alexmos@chromium.org
Change-Id: Ic0637a6038bed6e5334a26e1934bee81faad3b9e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 828529
Reviewed-on: https://chromium-review.googlesource.com/1012138
Reviewed-by: Ben Pastene <bpastene@chromium.org>
Commit-Queue: Ben Pastene <bpastene@chromium.org>
Cr-Commit-Position: refs/heads/master@{#550649}
1 parent 1e5a5fe
RTCRtpParameters-rtcp.html
<!doctype html>
<meta charset=utf-8>
<title>RTCRtpParameters rtcp</title>
<script src="/resources/testharness.js"></script>
<script src="/resources/testharnessreport.js"></script>
<script src="dictionary-helper.js"></script>
<script src="RTCRtpParameters-helper.js"></script>
<script>
'use strict';
// Test is based on the following editor draft:
// https://w3c.github.io/webrtc-pc/archives/20170605/webrtc.html
// The following helper functions are called from RTCRtpParameters-helper.js:
// validateSenderRtpParameters
/*
5.2. RTCRtpSender Interface
interface RTCRtpSender {
Promise<void> setParameters(optional RTCRtpParameters parameters);
RTCRtpParameters getParameters();
};
dictionary RTCRtpParameters {
DOMString transactionId;
sequence<RTCRtpEncodingParameters> encodings;
sequence<RTCRtpHeaderExtensionParameters> headerExtensions;
RTCRtcpParameters rtcp;
sequence<RTCRtpCodecParameters> codecs;
RTCDegradationPreference degradationPreference;
};
dictionary RTCRtcpParameters {
[readonly]
DOMString cname;
[readonly]
boolean reducedSize;
};
getParameters
- rtcp.cname is set to the CNAME of the associated RTCPeerConnection.
rtcp.reducedSize is set to true if reduced-size RTCP has been negotiated for
sending, and false otherwise.
*/
/*
5.2. setParameters
7. If parameters.encodings.length is different from N, or if any parameter
in the parameters argument, marked as a Read-only parameter, has a value
that is different from the corresponding parameter value returned from
sender.getParameters(), abort these steps and return a promise rejected
with a newly created InvalidModificationError. Note that this also applies
to transactionId.
*/
promise_test(t => {
const pc = new RTCPeerConnection();
const { sender } = pc.addTransceiver('audio');
const param = sender.getParameters();
validateSenderRtpParameters(param);
const { rtcp } = param;
if(rtcp === undefined) {
param.rtcp = { cname: 'foo' };
} else if(rtcp.cname === undefined) {
rtcp.cname = 'foo';
} else {
rtcp.cname = `${rtcp.cname}-modified`;
}
return promise_rejects(t, 'InvalidModificationError',
sender.setParameters(param));
}, `setParameters() with modified rtcp.cname should reject with InvalidModificationError`);
promise_test(t => {
const pc = new RTCPeerConnection();
const { sender } = pc.addTransceiver('audio');
const param = sender.getParameters();
validateSenderRtpParameters(param);
const { rtcp } = param;
if(rtcp === undefined) {
param.rtcp = { reducedSize: true };
} else if(rtcp.reducedSize === undefined) {
rtcp.reducedSize = true;
} else {
rtcp.reducedSize = !rtcp.reducedSize;
}
return promise_rejects(t, 'InvalidModificationError',
sender.setParameters(param));
}, `setParameters() with modified rtcp.reducedSize should reject with InvalidModificationError`);
</script>
Computing file changes ...
