Revision cdf5b3962f33d0a05af040097173d8cc827a7d73 authored by Trent Apted on 12 March 2018, 04:02:04 UTC, committed by Blink WPT Bot on 12 March 2018, 04:10:37 UTC
This reverts commit af1c15b16f99d290799c83d34c111bce52447026.
Reason for revert: suspected for persistent failures on Win7 Tests (dbg)(1)
Unexpected Failures:
* external/wpt/bluetooth/server/getPrimaryServices/blocklisted-services.https.html
* external/wpt/bluetooth/service/getCharacteristic/gen-blocklisted-characteristic.https.html
* external/wpt/bluetooth/service/getCharacteristics/blocklisted-characteristics.https.html
* external/wpt/bluetooth/service/getCharacteristics/gen-blocklisted-characteristic-with-uuid.https.html
* external/wpt/upgrade-insecure-requests/link-upgrade.sub.https.html
since
https://ci.chromium.org/buildbot/chromium.win/Win7%20Tests%20%28dbg%29%281%29/66761
errors like
15:59:42.310 5904 worker/4 external/wpt/bluetooth/service/getCharacteristics/gen-blocklisted-characteristic-with-uuid.https.html crashed, (stderr lines):
15:59:42.311 5904 CONSOLE MESSAGE: line 255: Web Bluetooth is experimental on this platform. See https://github.com/WebBluetoothCG/web-bluetooth/blob/gh-pages/implementation-status.md
15:59:42.327 1300 [1691/5755] external/wpt/bluetooth/service/getCharacteristics/gen-blocklisted-characteristic-with-uuid.https.html failed unexpectedly (content_shell crashed [pid=5644])
Original change's description:
> bluetooth: Use DeviceUUID in FakeBluetooth
>
> This change refactors the Web Bluetooth test API to use the
> DeviceUUIDs helper class defined in BluetoothDevice. Additionally,
> this change finishes the implementation of SimulateGATTServicesChanged,
> and as a result, tests are updated to set the next discovery response
> before calling this interface.
>
> BUG=719826
>
> Change-Id: I0f986eb7afe6fbf7ebaa80ac4b633d46a027b80d
> Reviewed-on: https://chromium-review.googlesource.com/939984
> Commit-Queue: Ovidio Henriquez <odejesush@chromium.org>
> Reviewed-by: Giovanni Ortuño Urquidi <ortuno@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#541577}
TBR=cco3@chromium.org,ortuno@chromium.org,odejesush@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: 719826
Change-Id: I02bb7066c6f1282191f7a24e91b3d2c5614b8104
Reviewed-on: https://chromium-review.googlesource.com/958741
Reviewed-by: Trent Apted <tapted@chromium.org>
Commit-Queue: Trent Apted <tapted@chromium.org>
Cr-Commit-Position: refs/heads/master@{#542421}
1 parent 9c9d8f2
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>
Computing file changes ...
