Skip to main content

Browse the archive

Revision b55e29597d92ab89063673f031151e2bdb4b9479 authored by Joe Downing on 22 March 2018, 07:35:35 UTC, committed by Chromium WPT Sync on 22 March 2018, 07:35:35 UTC 
Move KeyboardLock API methods to a 'keyboard' object
 
This change moves the KeyboardLock API methods to a 'keyboard'
namespace on the Navigator object.  We are doing this work now as
there has been a request for additional keyboard functionality that
would also be placed on the new keyboard object and we wanted to
move the KeyboardLock methods there for consistency before we launch.

KeyboardLock API Spec is here:
https://w3c.github.io/keyboard-lock/#API

Old calling pattern:
Navigator.keyboardLock();
Navigator.keyboardUnlock();

New calling pattern:
Navigator.keyboard.lock();
Navigator.keyboard.unlock();

Note: The main logic in the KeyboardLock.cpp class and tests is the
same as it was, however the file changed enough that git does not
recognize it as a file move.

BUG=680809

Change-Id: I234b2ab12d5ecd44c894ed5103863fd96fd548d4
Reviewed-on: https://chromium-review.googlesource.com/969656
Reviewed-by: Philip Jägenstedt <foolip@chromium.org>
Reviewed-by: Gary Kacmarcik <garykac@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544996}
1 parent 1a8c195
Raw File
RTCPeerConnection-setRemoteDescription-answer.html 
<!doctype html>
<meta charset=utf-8>
<title>RTCPeerConnection.prototype.setRemoteDescription - answer</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>                      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.2.3.  Otherwise, if description is set as a remote description, then run one of
              the following steps:
        - If description is of type "answer", then this completes an offer answer
          negotiation.

          Set connection's currentRemoteDescription to description and
          currentLocalDescription to the value of pendingLocalDescription.

          Set both pendingRemoteDescription and pendingLocalDescription to null.

          Finally setconnection's signaling state to stable.
   */
  promise_test(t => {
    const pc = new RTCPeerConnection();
    test_state_change_event(t, pc, ['have-local-offer', 'stable']);

    return pc.createOffer({ offerToReceiveVideo: true })
    .then(offer =>
      pc.setLocalDescription(offer)
      .then(() => generateAnswer(offer))
      .then(answer =>
        pc.setRemoteDescription(answer)
        .then(() => {
          assert_equals(pc.signalingState, 'stable');

          assert_session_desc_equals(pc.localDescription, offer);
          assert_session_desc_equals(pc.remoteDescription, answer);

          assert_session_desc_equals(pc.currentLocalDescription, offer);
          assert_session_desc_equals(pc.currentRemoteDescription, answer);

          assert_equals(pc.pendingLocalDescription, null);
          assert_equals(pc.pendingRemoteDescription, null);
        })));
  }, 'setRemoteDescription() with valid state and answer should succeed');

  /*
    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 "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: 'answer', sdp: offer.sdp })));
  }, 'Calling setRemoteDescription(answer) from stable state should reject with InvalidStateError');

  promise_test(t => {
    const pc = new RTCPeerConnection();

    return pc.createOffer()
    .then(offer =>
      pc.setRemoteDescription(offer)
      .then(() => generateAnswer(offer)))
    .then(answer =>
      promise_rejects(t, 'InvalidStateError',
        pc.setRemoteDescription(answer)));

  }, 'Calling setRemoteDescription(answer) from have-remote-offer state should reject with InvalidStateError');

</script>
back to top