W3C home > Mailing lists > Public > public-html-media@w3.org > July 2015

[encrypted-media] Be explicit about aborting steps when resolving a promise early

From: ddorwin via GitHub <sysbot+gh@w3.org>
Date: Tue, 07 Jul 2015 22:37:48 +0000
To: public-html-media@w3.org
Message-ID: <issues.opened-93645416-1436308668-sysbot+gh@w3.org>
ddorwin has just created a new issue for 
https://github.com/w3c/encrypted-media:

== Be explicit about aborting steps when resolving a promise early ==
### Resolve steps
`load()` step 8.8.1 says:
>If there is no data stored for the sanitized session ID in the 
origin, resolve promise with false.

It is followed by steps intended to only be applied when the promise 
is not resolved.

It turns out that this behavior is specified by the following 
statement before the IDL in section 6:
>The steps of an algorithm are always aborted when resolving or 
rejecting a promise.

However:
1. This seems unlikely to be assumed when reading the algorithm alone 
(as compared to bailing after rejection).
2. This is the only location where we resolve early (other than 
`requestMediaKeySystemAccess()` - see below).
3. Depending on the outcome of #14, we _might_ want to resolve a 
promise then run more steps.

Therefore, I think we should remove "resolving or " from this 
statement (and the other two instances) and explicitly abort  the 
`load()` algorithm in step 8.8.1.

### Reject steps
I forget why we removed " and abort these steps" from all the reject 
steps and added these three instances of this statement. Perhaps to be
 more concise and highlight the unique portions of each such step. 
It's certainly less text than including that phrase in the 
approximately 40 such steps, but it is less explicit.

### `requestMediaKeySystemAccess()` bugs
1. Section 3 does not have such a statement.
2. However, there are several promise rejection steps that do not 
specify that the remaining steps should be aborted.
3. Step 7.3.3.2 is inconsistent with the rest of the spec in that it 
still says " and abort these steps." (In light of (1) above, this is 
actually correct.

See https://github.com/w3c/encrypted-media/issues/71
Received on Tuesday, 7 July 2015 22:37:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:03 UTC