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
Raw File
RTCPeerConnection-setRemoteDescription-pranswer.html
<!doctype html>
<meta charset=utf-8>
<title>RTCPeerConnection.prototype.setRemoteDescription pranswer</title>
<script src="/resources/testharness.js"></script>
<script src="/resources/testharnessreport.js"></script>
<script src="RTCPeerConnection-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 RTCPeerConnection-helper.js:
  //   generateOffer
  //   generateAnswer
  //   assert_session_desc_equals
  //   test_state_change_event

  /*
    4.3.2.  Interface Definition
      [Constructor(optional RTCConfiguration configuration)]
      interface RTCPeerConnection : EventTarget {
        Promise<void>                      setLocalDescription(
            RTCSessionDescriptionInit description);

        readonly attribute RTCSessionDescription? localDescription;
        readonly attribute RTCSessionDescription? currentLocalDescription;
        readonly attribute RTCSessionDescription? pendingLocalDescription;

        Promise<void>                      setRemoteDescription(
            RTCSessionDescriptionInit description);

        readonly attribute RTCSessionDescription? remoteDescription;
        readonly attribute RTCSessionDescription? currentRemoteDescription;
        readonly attribute RTCSessionDescription? pendingRemoteDescription;
        ...
      };

    4.6.2.  RTCSessionDescription Class
      dictionary RTCSessionDescriptionInit {
        required RTCSdpType type;
                 DOMString  sdp = "";
      };

    4.6.1.  RTCSdpType
      enum RTCSdpType {
        "offer",
        "pranswer",
        "answer",
        "rollback"
      };
   */

  /*
    4.3.1.6.  Set the RTCSessionSessionDescription
      2.1.3.  If the description's type is invalid for the current signaling state of
              connection, then reject p with a newly created InvalidStateError and abort
              these steps.

    [JSEP]
      5.6.  If the type is "pranswer" or "answer", the PeerConnection state MUST be either
            "have-local-offer" or "have-remote-pranswer".
   */
  promise_test(t => {
    const pc = new RTCPeerConnection();

    return pc.createOffer()
    .then(offer =>
      promise_rejects(t, 'InvalidStateError',
        pc.setRemoteDescription({ type: 'pranswer', sdp: offer.sdp })));
  }, 'setRemoteDescription(pranswer) from stable state should reject with InvalidStateError');

  /*
    4.3.1.6.  Set the RTCSessionSessionDescription
      2.2.3.  Otherwise, if description is set as a remote description, then run one
              of the following steps:
        - If description is of type "pranswer", then set
          connection.pendingRemoteDescription to description and signaling state
          to have-remote-pranswer.
   */
  promise_test(t => {
    const pc = new RTCPeerConnection();
    test_state_change_event(t, pc, ['have-local-offer', 'have-remote-pranswer']);

    return pc.createOffer({ offerToReceiveVideo: true })
    .then(offer =>
      pc.setLocalDescription(offer)
      .then(() => generateAnswer(offer))
      .then(answer => {
        const pranswer = { type: 'pranswer', sdp: answer.sdp };

        return pc.setRemoteDescription(pranswer)
        .then(() => {
          assert_equals(pc.signalingState, 'have-remote-pranswer');

          assert_session_desc_equals(pc.localDescription, offer);
          assert_session_desc_equals(pc.pendingLocalDescription, offer);
          assert_equals(pc.currentLocalDescription, null);

          assert_session_desc_equals(pc.remoteDescription, pranswer);
          assert_session_desc_equals(pc.pendingRemoteDescription, pranswer);
          assert_equals(pc.currentRemoteDescription, null);
        });
      }));
  }, 'setRemoteDescription(pranswer) from have-local-offer state should succeed');

  promise_test(t => {
    const pc = new RTCPeerConnection();
    test_state_change_event(t, pc, ['have-local-offer', 'have-remote-pranswer']);

    return pc.createOffer({ offerToReceiveVideo: true })
    .then(offer =>
      pc.setLocalDescription(offer)
      .then(() => generateAnswer(offer))
      .then(answer => {
        const pranswer = { type: 'pranswer', sdp: answer.sdp };

        return pc.setRemoteDescription(pranswer)
        .then(() => pc.setRemoteDescription(pranswer));
      }));
  }, 'setRemoteDescription(pranswer) multiple times should succeed');

  promise_test(t => {
    const pc = new RTCPeerConnection();
    test_state_change_event(t, pc, ['have-local-offer', 'have-remote-pranswer', 'stable']);

    return pc.createOffer({ offerToReceiveVideo: true })
    .then(offer =>
      pc.setLocalDescription(offer)
      .then(() => generateAnswer(offer))
      .then(answer => {
        const pranswer = { type: 'pranswer', sdp: answer.sdp };

        return pc.setRemoteDescription(pranswer)
        .then(() => pc.setRemoteDescription(answer))
        .then(() => {
          assert_equals(pc.signalingState, 'stable');

          assert_session_desc_equals(pc.localDescription, offer);
          assert_session_desc_equals(pc.currentLocalDescription, offer);
          assert_equals(pc.pendingLocalDescription, null);

          assert_session_desc_equals(pc.remoteDescription, answer);
          assert_session_desc_equals(pc.currentRemoteDescription, answer);
          assert_equals(pc.pendingRemoteDescription, null);
        });
      }));
  }, 'setRemoteDescription(answer) from have-remote-pranswer state should succeed');

</script>
back to top