third_party/WebKit/LayoutTests/fast/peerconnection/RTCPeerConnectionIceEvent-constructor.html - Issue 2494553002: Rename RTCIceCandidateEvent to RTCPeerConnectionIceEvent and expose.

Side by Side Diff: third_party/WebKit/LayoutTests/fast/peerconnection/RTCPeerConnectionIceEvent-constructor.html

Issue 2494553002: Rename RTCIceCandidateEvent to RTCPeerConnectionIceEvent and expose. (Closed)

Patch Set: Added layout test Created 4 years, 1 month ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

« no previous file with comments | « no previous file | third_party/WebKit/LayoutTests/platform/linux/virtual/stable/webexposed/global-interface-listing-expected.txt » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
(Empty)
	1 <!DOCTYPE html>

	2 <meta charset="utf-8">

	3 <title>RTCPeerConnectionIceEvent constructor</title>

	4 <script src="../../resources/testharness.js"></script>

	5 <script src="../../resources/testharnessreport.js"></script>

	6 <script>

	7 test(function() {

	8 assert_equals(RTCPeerConnectionIceEvent.length, 1);

	9 var e = new RTCPeerConnectionIceEvent('type');

	10 assert_equals(e.candidate, null);

	11 // TODO(lunalu): default for e.url should be "null" instead of "undefined".
	foolip 2016/11/11 21:22:05 I think this is OK so that this test must be updat I think this is OK so that this test must be updated if support is added, but if upstream to web-platform-tests this would be in conflict with what the spec says. OK to leave as is, but it would also be totally fine to not test url at all until it's implemented, which could be never. lunalu1 2016/11/15 18:09:24 Done. Show quoted text On 2016/11/11 21:22:05, foolip wrote: > I think this is OK so that this test must be updated if support is added, but if > upstream to web-platform-tests this would be in conflict with what the spec > says. OK to leave as is, but it would also be totally fine to not test url at > all until it's implemented, which could be never. Done.
	12 assert_equals(e.url, undefined);

	13 assert_false(e.bubbles);

	14 assert_false(e.cancelable);

	15 }, 'RTCPeerConnectionIceEvent constructor with no candidate attribute provivded' );

	16

	17 test(function() {

	18 var e = new RTCPeerConnectionIceEvent('type', { candidate: null });

	19 assert_equals(e.candidate, null);

	20 }, 'RTCPeerConnectionIceEvent constructor with cnadidate paased as "null".');

	21

	22 test(function() {

	23 var e = new RTCPeerConnectionIceEvent('type', { candidate: undefined });

	24 // TODO(lunalu): should be "undefined" instead of "null".
	foolip 2016/11/11 21:22:05 Actually, null is correct. The reason is a bit nua Actually, null is correct. The reason is a bit nuanced. When converting dictionaries in https://heycam.github.io/webidl/#es-dictionary there's a "Get(V, key)" bit, which would return undefined both if the property is there, and if it's there but has the value undefined. And then undefined is treated as missing. So null here can be said to be the default value, not the result of trying to convert undefined to the type "RTCIceCandidate?" That, per https://heycam.github.io/webidl/#es-nullable-type would have resulted in null because of "Otherwise, if V is null or undefined, then return the IDL nullable type T? value null." The difference doesn't matter here, it's just trivia. lunalu1 2016/11/15 18:09:24 Done. Show quoted text On 2016/11/11 21:22:05, foolip wrote: > Actually, null is correct. The reason is a bit nuanced. When converting > dictionaries in https://heycam.github.io/webidl/#es-dictionary there's a "Get(V, > key)" bit, which would return undefined both if the property is there, and if > it's there but has the value undefined. And then undefined is treated as > missing. So null here can be said to be the default value, not the result of > trying to convert undefined to the type "RTCIceCandidate?" That, per > https://heycam.github.io/webidl/#es-nullable-type would have resulted in null > because of "Otherwise, if V is null or undefined, then return the IDL nullable > type T? value null." > > The difference doesn't matter here, it's just trivia. Done.
	25 assert_equals(e.candidate, null);

	26 }, 'RTCPeerConnectionIceEvent constructor with candidate paased as "undefined".' );

	27

	28 test(function() {

	29 var c = new RTCIceCandidate({ candidate: 'candidate', sdpMid: 'sdpMid', sdpMLi neIndex: 1 });
	foolip 2016/11/11 21:22:05 Unrelated: A look at RTCIceCandidate.idl shows tha Unrelated: A look at RTCIceCandidate.idl shows that there are plenty of small differences to the spec. Another day. lunalu1 2016/11/15 18:09:24 Done. Show quoted text On 2016/11/11 21:22:05, foolip wrote: > Unrelated: A look at RTCIceCandidate.idl shows that there are plenty of small > differences to the spec. Another day. Done.
	30 var e = new RTCPeerConnectionIceEvent('type', { candidate: c, url: 'url', bubb les: true, cancelable: true});

	31 assert_equals(e.candidate, c);

	32 assert_equals(e.url, undefined);

	33 assert_true(e.bubbles);

	34 assert_true(e.cancelable);

	35 }, 'RTCPeerConnectionIceEvent constructor with full arguments.');

	36 </script>

OLD	NEW