Mirrors/servo
1
0
Fork 0
mirror of https://github.com/servo/servo.git synced 2025-08-12 17:05:33 +01:00
Code Issues Projects Releases Packages Wiki Activity

Update web-platform-tests to revision 8a2ceb5f18911302b7a5c1cd2791f4ab50ad4326

Browse source
This commit is contained in:
Josh Matthews 2017-10-12 09:25:50 -04:00
parent 462c272380
commit 1f531f66ea
5377 changed files with 174916 additions and 84369 deletions
Download patch file Download diff file Expand all files Collapse all files

122
tests/wpt/web-platform-tests/webrtc/coverage/RTCDTMFSender.txt Normal file
View file

@ -0,0 +1,122 @@
Coverage is based on the following editor draft:
https://w3c.github.io/webrtc-pc/archives/20170605/webrtc.html
7. insertDTMF
[Trivial]
- The tones parameter is treated as a series of characters.
[RTCDTMFSender-insertDTMF]
- The characters 0 through 9, A through D, #, and * generate the associated
DTMF tones.
[RTCDTMFSender-insertDTMF]
- The characters a to d MUST be normalized to uppercase on entry and are equivalent
to A to D.
[RTCDTMFSender-insertDTMF]
- As noted in [RTCWEB-AUDIO] Section 3, support for the characters 0 through 9,
A through D, #, and * are required.
[RTCDTMFSender-insertDTMF]
- The character ',' MUST be supported, and indicates a delay of 2 seconds before
processing the next character in the tones parameter.
[RTCDTMFSender-insertDTMF]
- All other characters (and only those other characters) MUST
be considered unrecognized.
[Trivial]
- The duration parameter indicates the duration in ms to use for each character passed
in the tones parameters.
[RTCDTMFSender-ontonechange]
- The duration cannot be more than 6000 ms or less than 40 ms.
[RTCDTMFSender-ontonechange]
- The default duration is 100 ms for each tone.
[RTCDTMFSender-ontonechange]
- The interToneGap parameter indicates the gap between tones in ms. The user agent
clamps it to at least 30 ms. The default value is 70 ms.
[Untestable]
- The browser MAY increase the duration and interToneGap times to cause the times
that DTMF start and stop to align with the boundaries of RTP packets but it MUST
not increase either of them by more than the duration of a single RTP audio packet.
[Trivial]
When the insertDTMF() method is invoked, the user agent MUST run the following steps:
[Trivial]
1. let sender be the RTCRtpSender used to send DTMF.
[Trivial]
2. Let transceiver be the RTCRtpTransceiver object associated with sender.
[RTCDTMFSender-insertDTMF]
3. If transceiver.stopped is true, throw an InvalidStateError.
[RTCDTMFSender-insertDTMF]
4. If transceiver.currentDirection is recvonly or inactive, throw an
InvalidStateError.
[Trivial]
5. Let tones be the method's first argument.
[RTCDTMFSender-insertDTMF]
6. If tones contains any unrecognized characters, throw an InvalidCharacterError.
[RTCDTMFSender-insertDTMF]
7. Set the object's toneBuffer attribute to tones.
[RTCDTMFSender-ontonechange]
8. If the value of the duration parameter is less than 40, set it to 40.
[RTCDTMFSender-ontonechange-long]
If, on the other hand, the value is greater than 6000, set it to 6000.
[RTCDTMFSender-ontonechange]
9. If the value of the interToneGap parameter is less than 30, set it to 30.
[RTCDTMFSender-ontonechange]
10. If toneBuffer is an empty string, abort these steps.
[RTCDTMFSender-ontonechange]
11. If a Playout task is scheduled to be run; abort these steps;
[RTCDTMFSender-ontonechange]
otherwise queue a task that runs the following steps (Playout task):
[RTCDTMFSender-ontonechange]
1. If transceiver.stopped is true, abort these steps.
[RTCDTMFSender-ontonechange]
2. If transceiver.currentDirection is recvonly or inactive, abort these steps.
[RTCDTMFSender-ontonechange]
3. If toneBuffer is an empty string, fire an event named tonechange with an
empty string at the RTCDTMFSender object and abort these steps.
[RTCDTMFSender-ontonechange]
4. Remove the first character from toneBuffer and let that character be tone.
[Untestable]
5. Start playout of tone for duration ms on the associated RTP media stream,
using the appropriate codec.
[RTCDTMFSender-ontonechange]
6. Queue a task to be executed in duration + interToneGap ms from now that
runs the steps labelled Playout task.
[RTCDTMFSender-ontonechange]
7. Fire an event named tonechange with a string consisting of tone at the
RTCDTMFSender object.
Coverage Report
Tested 31
Not Tested 0
Untestable 1
Total 32

220
tests/wpt/web-platform-tests/webrtc/coverage/identity.txt Normal file
View file

@ -0,0 +1,220 @@
Coverage is based on the following editor draft:
https://w3c.github.io/webrtc-pc/archives/20170605/webrtc.html
9.3 Requesting Identity Assertions
[Trivial]
The identity assertion request process is triggered by a call to createOffer,
createAnswer, or getIdentityAssertion. When these calls are invoked and an
identity provider has been set, the following steps are executed:
[RTCPeerConnection-getIdentityAssertion]
1. The RTCPeerConnection instantiates an IdP as described in Identity Provider
Selection and Registering an IdP Proxy. If the IdP cannot be loaded, instantiated,
or the IdP proxy is not registered, this process fails.
[RTCPeerConnection-getIdentityAssertion]
2. The RTCPeerConnection invokes the generateAssertion method on the
RTCIdentityProvider methods registered by the IdP.
[RTCPeerConnection-getIdentityAssertion]
The RTCPeerConnection generates the contents parameter to this method as
described in [RTCWEB-SECURITY-ARCH]. The value of contents includes the
fingerprint of the certificate that was selected or generated during the
construction of the RTCPeerConnection. The origin parameter contains the
origin of the script that calls the RTCPeerConnection method that triggers
this behavior. The usernameHint value is the same value that is provided
to setIdentityProvider, if any such value was provided.
[RTCPeerConnection-getIdentityAssertion]
3. The IdP proxy returns a Promise to the RTCPeerConnection. The IdP proxy is
expected to generate the identity assertion asynchronously.
[RTCPeerConnection-getIdentityAssertion]
If the user has been authenticated by the IdP, and the IdP is able to generate
an identity assertion, the IdP resolves the promise with an identity assertion
in the form of an RTCIdentityAssertionResult .
[RTCPeerConnection-getIdentityAssertion]
This step depends entirely on the IdP. The methods by which an IdP authenticates
users or generates assertions is not specified, though they could involve
interacting with the IdP server or other servers.
[RTCPeerConnection-getIdentityAssertion]
4. If the IdP proxy produces an error or returns a promise that does not resolve
to a valid RTCIdentityValidationResult (see 9.5 IdP Error Handling), then
identity validation fails.
[Untestable]
5. The RTCPeerConnection MAY store the identity assertion for use with future
offers or answers. If a fresh identity assertion is needed for any reason,
applications can create a new RTCPeerConnection.
[RTCPeerConnection-getIdentityAssertion]
6. If the identity request was triggered by a createOffer() or createAnswer(),
then the assertion is converted to a JSON string, base64-encoded and inserted
into an a=identity attribute in the session description.
[RTCPeerConnection-getIdentityAssertion]
If assertion generation fails, then the promise for the corresponding function call
is rejected with a newly created OperationError.
9.3.1 User Login Procedure
[RTCPeerConnection-getIdentityAssertion]
An IdP MAY reject an attempt to generate an identity assertion if it is unable to
verify that a user is authenticated. This might be due to the IdP not having the
necessary authentication information available to it (such as cookies).
[RTCPeerConnection-getIdentityAssertion]
Rejecting the promise returned by generateAssertion will cause the error to propagate
to the application. Login errors are indicated by rejecting the promise with an RTCError
with errorDetail set to "idp-need-login".
[RTCPeerConnection-getIdentityAssertion]
The URL to login at will be passed to the application in the idpLoginUrl attribute of
the RTCPeerConnection.
[Out of Scope]
An application can load the login URL in an IFRAME or popup window; the resulting page
then SHOULD provide the user with an opportunity to enter any information necessary to
complete the authorization process.
[Out of Scope]
Once the authorization process is complete, the page loaded in the IFRAME or popup sends
a message using postMessage [webmessaging] to the page that loaded it (through the
window.opener attribute for popups, or through window.parent for pages loaded in an IFRAME).
The message MUST consist of the DOMString "LOGINDONE". This message informs the application
that another attempt at generating an identity assertion is likely to be successful.
9.4. Verifying Identity Assertions
The identity assertion request process involves the following asynchronous steps:
[TODO]
1. The RTCPeerConnection awaits any prior identity validation. Only one identity
validation can run at a time for an RTCPeerConnection. This can happen because
the resolution of setRemoteDescription is not blocked by identity validation
unless there is a target peer identity.
[RTCPeerConnection-peerIdentity]
2. The RTCPeerConnection loads the identity assertion from the session description
and decodes the base64 value, then parses the resulting JSON. The idp parameter
of the resulting dictionary contains a domain and an optional protocol value
that identifies the IdP, as described in [RTCWEB-SECURITY-ARCH].
[RTCPeerConnection-peerIdentity]
3. The RTCPeerConnection instantiates the identified IdP as described in 9.1.1
Identity Provider Selection and 9.2 Registering an IdP Proxy. If the IdP
cannot be loaded, instantiated or the IdP proxy is not registered, this
process fails.
[RTCPeerConnection-peerIdentity]
4. The RTCPeerConnection invokes the validateAssertion method registered by the IdP.
[RTCPeerConnection-peerIdentity]
The assertion parameter is taken from the decoded identity assertion. The origin
parameter contains the origin of the script that calls the RTCPeerConnection
method that triggers this behavior.
[RTCPeerConnection-peerIdentity]
5. The IdP proxy returns a promise and performs the validation process asynchronously.
[Out of Scope]
The IdP proxy verifies the identity assertion using whatever means necessary.
Depending on the authentication protocol this could involve interacting with the
IdP server.
[RTCPeerConnection-peerIdentity]
6. If the IdP proxy produces an error or returns a promise that does not resolve
to a valid RTCIdentityValidationResult (see 9.5 IdP Error Handling), then
identity validation fails.
[RTCPeerConnection-peerIdentity]
7. Once the assertion is successfully verified, the IdP proxy resolves the promise
with an RTCIdentityValidationResult containing the validated identity and the
original contents that are the payload of the assertion.
[RTCPeerConnection-peerIdentity]
8. The RTCPeerConnection decodes the contents and validates that it contains a
fingerprint value for every a=fingerprint attribute in the session description.
This ensures that the certificate used by the remote peer for communications
is covered by the identity assertion.
[RTCPeerConnection-peerIdentity]
9. The RTCPeerConnection validates that the domain portion of the identity matches
the domain of the IdP as described in [RTCWEB-SECURITY-ARCH]. If this check fails
then the identity validation fails.
[RTCPeerConnection-peerIdentity]
10. The RTCPeerConnection resolves the peerIdentity attribute with a new instance
of RTCIdentityAssertion that includes the IdP domain and peer identity.
[Out of Scope]
11. The user agent MAY display identity information to a user in its UI. Any user
identity information that is displayed in this fashion MUST use a mechanism that
cannot be spoofed by content.
[RTCPeerConnection-peerIdentity]
If identity validation fails, the peerIdentity promise is rejected with a newly
created OperationError.
[RTCPeerConnection-peerIdentity]
If identity validation fails and there is a target peer identity for the
RTCPeerConnection, the promise returned by setRemoteDescription MUST be rejected
with the same DOMException.
9.5. IdP Error Handling
[RTCPeerConnection-getIdentityAssertion]
- A RTCPeerConnection might be configured with an identity provider, but loading of
the IdP URI fails. Any procedure that attempts to invoke such an identity provider
and cannot load the URI fails with an RTCError with errorDetail set to
"idp-load-failure" and the httpRequestStatusCode attribute of the error set to the
HTTP status code of the response.
[Untestable]
- If the IdP loads fails due to the TLS certificate used for the HTTPS connection not
being trusted, it fails with an RTCError with errorDetail set to "idp-tls-failure".
This typically happens when the IdP uses certificate pinning and an intermediary
such as an enterprise firewall has intercepted the TLS connection.
[RTCPeerConnection-getIdentityAssertion]
- If the script loaded from the identity provider is not valid JavaScript or does not
implement the correct interfaces, it causes an IdP failure with an RTCError with
errorDetail set to "idp-bad-script-failure".
[TODO]
- An apparently valid identity provider might fail in several ways.
If the IdP token has expired, then the IdP MUST fail with an RTCError with
errorDetail set to "idp-token-expired".
If the IdP token is not valid, then the IdP MUST fail with an RTCError with
errorDetail set to "idp-token-invalid".
[Untestable]
- The user agent SHOULD limit the time that it allows for an IdP to 15 seconds.
This includes both the loading of the IdP proxy and the identity assertion
generation or validation. Failure to do so potentially causes the corresponding
operation to take an indefinite amount of time. This timer can be cancelled when
the IdP proxy produces a response. Expiration of this timer cases an IdP failure
with an RTCError with errorDetail set to "idp-timeout".
[RTCPeerConnection-getIdentityAssertion]
- If the identity provider requires the user to login, the operation will fail
RTCError with errorDetail set to "idp-need-login" and the idpLoginUrl attribute
of the error set to the URL that can be used to login.
[RTCPeerConnection-peerIdentity]
- Even when the IdP proxy produces a positive result, the procedure that uses this
information might still fail. Additional validation of a RTCIdentityValidationResult
value is still necessary. The procedure for validation of identity assertions
describes additional steps that are required to successfully validate the output
of the IdP proxy.
Coverage Report
Tested 29
Not Tested 2
Untestable 4
Total 35

240
tests/wpt/web-platform-tests/webrtc/coverage/set-session-description.txt Normal file
View file

@ -0,0 +1,240 @@
Coverage Report is based on the following editor draft:
https://w3c.github.io/webrtc-pc/archives/20170605/webrtc.html
4.3.1.6 Set the RTCSessionSessionDescription
[Trivial]
1. Let p be a new promise.
[Trivial]
2. In parallel, start the process to apply description as described in [JSEP]
(section 5.5. and section 5.6.).
[Trivial]
1. If the process to apply description fails for any reason, then user agent
MUST queue a task that runs the following steps:
[Untestable]
1. If connection's [[IsClosed]] slot is true, then abort these steps.
[Untestable]
2. If elements of the SDP were modified, then reject p with a newly created
InvalidModificationError and abort these steps.
[RTCPeerConnection-setLocalDescription-answer]
[RTCPeerConnection-setRemoteDescription-offer]
[RTCPeerConnection-setRemoteDescription-answer]
3. If the description's type is invalid for the current signaling state of
connection as described in [JSEP] (section 5.5. and section 5.6.), then
reject p with a newly created InvalidStateError and abort these steps.
[RTCPeerConnection-setRemoteDescription-offer]
4. If the content of description is not valid SDP syntax, then reject p
with an RTCError (with errorDetail set to "sdp-syntax-error" and the
sdpLineNumber attribute set to the line number in the SDP where the
syntax error was detected) and abort these steps.
[Untestable]
5. If the content of description is invalid, then reject p with a newly
created InvalidAccessError and abort these steps.
[Untestable]
6. For all other errors, for example if description cannot be applied at
the media layer, reject p with a newly created OperationError.
[Trivial]
2. If description is applied successfully, the user agent MUST queue a task
that runs the following steps:
[Untestable]
1. If connection's [[isClosed]] slot is true, then abort these steps.
[RTCPeerConnection-setLocalDescription]
2. If description is set as a local description, then run one of the
following steps:
[RTCPeerConnection-setLocalDescription-offer]
- If description is of type "offer", set connection.pendingLocalDescription
to description and signaling state to have-local-offer.
[RTCPeerConnection-setLocalDescription-answer]
- If description is of type "answer", then this completes an offer answer
negotiation.
Set connection's currentLocalDescription to description and
currentRemoteDescription to the value of pendingRemoteDescription.
Set both pendingRemoteDescription and pendingLocalDescription to null.
Finally set connection's signaling state to stable
[RTCPeerConnection-setLocalDescription-rollback]
- If description is of type "rollback", then this is a rollback. Set
connection.pendingLocalDescription to null and signaling state to stable.
[RTCPeerConnection-setLocalDescription-pranswer]
- If description is of type "pranswer", then set
connection.pendingLocalDescription to description and signaling state to
have-local-pranswer.
[RTCPeerConnection-setRemoteDescription]
3. Otherwise, if description is set as a remote description, then run one of the
following steps:
[RTCPeerConnection-setRemoteDescription-offer]
- If description is of type "offer", set connection.pendingRemoteDescription
attribute to description and signaling state to have-remote-offer.
[RTCPeerConnection-setRemoteDescription-answer]
- 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
[RTCPeerConnection-setRemoteDescription-rollback]
- If description is of type "rollback", then this is a rollback.
Set connection.pendingRemoteDescription to null and signaling state to stable.
[RTCPeerConnection-setRemoteDescription-rollback]
- If description is of type "pranswer", then set
connection.pendingRemoteDescription to description and signaling state
to have-remote-pranswer.
[RTCPeerConnection-setLocalDescription]
[RTCPeerConnection-setRemoteDescription]
4. If connection's signaling state changed above, fire a simple event named
signalingstatechange at connection.
[TODO]
5. If description is of type "answer", and it initiates the closure of an existing
SCTP association, as defined in [SCTP-SDP], Sections 10.3 and 10.4, set the value
of connection's [[sctpTransport]] internal slot to null.
[RTCSctpTransport]
6. If description is of type "answer" or "pranswer", then run the following steps:
[RTCSctpTransport]
1. If description initiates the establishment of a new SCTP association,
as defined in [SCTP-SDP], Sections 10.3 and 10.4, set the value of connection's
[[sctpTransport]] internal slot to a newly created RTCSctpTransport.
[TODO]
2. If description negotiates the DTLS role of the SCTP transport, and there is an
RTCDataChannel with a null id, then generate an ID according to
[RTCWEB-DATA-PROTOCOL].
[Untestable]
If no available ID could be generated, then run the following steps:
[Untestable]
1. Let channel be the RTCDataChannel object for which an ID could not be
generated.
[Untestable]
2. Set channel's readyState attribute to closed.
[Untestable]
3. Fire an event named error with a ResourceInUse exception at channel.
[Untestable]
4. Fire a simple event named close at channel.
[TODO RTCPeerConnection-setDescription-transceiver]
7. If description is set as a local description, then run the following steps for
each media description in description that is not yet associated with an
RTCRtpTransceiver object:
[TODO RTCPeerConnection-setDescription-transceiver]
1. Let transceiver be the RTCRtpTransceiver used to create the media
description.
[TODO RTCPeerConnection-setDescription-transceiver]
2. Set transceiver's mid value to the mid of the corresponding media
description.
[RTCPeerConnection-ontrack]
8. If description is set as a remote description, then run the following steps
for each media description in description:
[TODO RTCPeerConnection-setDescription-transceiver]
1. As described by [JSEP] (section 5.9.), attempt to find an existing
RTCRtpTransceiver object, transceiver, to represent the media description.
[RTCPeerConnection-ontrack]
2. If no suitable transceiver is found (transceiver is unset), run the following
steps:
[RTCPeerConnection-ontrack]
1. Create an RTCRtpSender, sender, from the media description.
[RTCPeerConnection-ontrack]
2. Create an RTCRtpReceiver, receiver, from the media description.
[RTCPeerConnection-ontrack]
3. Create an RTCRtpTransceiver with sender, receiver and direction, and let
transceiver be the result.
[RTCPeerConnection-ontrack]
3. Set transceiver's mid value to the mid of the corresponding media description.
If the media description has no MID, and transceiver's mid is unset, generate
a random value as described in [JSEP] (section 5.9.).
[RTCPeerConnection-ontrack]
4. If the direction of the media description is sendrecv or sendonly, and
transceiver.receiver.track has not yet been fired in a track event, process
the remote track for the media description, given transceiver.
[TODO RTCPeerConnection-setDescription-transceiver]
5. If the media description is rejected, and transceiver is not already stopped,
stop the RTCRtpTransceiver transceiver.
[TODO RTCPeerConnection-setDescription-transceiver]
9. If description is of type "rollback", then run the following steps:
[TODO RTCPeerConnection-setDescription-transceiver]
1. If the mid value of an RTCRtpTransceiver was set to a non-null value by
the RTCSessionDescription that is being rolled back, set the mid value
of that transceiver to null, as described by [JSEP] (section 4.1.8.2.).
[TODO RTCPeerConnection-setDescription-transceiver]
2. If an RTCRtpTransceiver was created by applying the RTCSessionDescription
that is being rolled back, and a track has not been attached to it via
addTrack, remove that transceiver from connection's set of transceivers,
as described by [JSEP] (section 4.1.8.2.).
[TODO RTCPeerConnection-setDescription-transceiver]
3. Restore the value of connection's [[SctpTransport]] internal slot to its
value at the last stable signaling state.
[RTCPeerConnection-onnegotiationneeded]
10. If connection's signaling state is now stable, update the negotiation-needed
flag. If connection's [[NegotiationNeeded]] slot was true both before and after
this update, queue a task that runs the following steps:
[Untestable]
1. If connection's [[IsClosed]] slot is true, abort these steps.
[RTCPeerConnection-onnegotiationneeded]
2. If connection's [[NegotiationNeeded]] slot is false, abort these steps.
[RTCPeerConnection-onnegotiationneeded]
3. Fire a simple event named negotiationneeded at connection.
[Trivial]
11. Resolve p with undefined.
[Trivial]
3. Return p.
Coverage Report
Tested 35
Not Tested 15
Untestable 8
Total 58