{"action":"created","issue":{"url":"https://api.github.com/repos/w3c/encrypted-media/issues/284","repository_url":"https://api.github.com/repos/w3c/encrypted-media","labels_url":"https://api.github.com/repos/w3c/encrypted-media/issues/284/labels{/name}","comments_url":"https://api.github.com/repos/w3c/encrypted-media/issues/284/comments","events_url":"https://api.github.com/repos/w3c/encrypted-media/issues/284/events","html_url":"https://github.com/w3c/encrypted-media/issues/284","id":167918259,"number":284,"title":"'waitingforkey' event has no inverse","user":{"login":"joeyparrish","id":6843156,"avatar_url":"https://avatars.githubusercontent.com/u/6843156?v=3","gravatar_id":"","url":"https://api.github.com/users/joeyparrish","html_url":"https://github.com/joeyparrish","followers_url":"https://api.github.com/users/joeyparrish/followers","following_url":"https://api.github.com/users/joeyparrish/following{/other_user}","gists_url":"https://api.github.com/users/joeyparrish/gists{/gist_id}","starred_url":"https://api.github.com/users/joeyparrish/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/joeyparrish/subscriptions","organizations_url":"https://api.github.com/users/joeyparrish/orgs","repos_url":"https://api.github.com/users/joeyparrish/repos","events_url":"https://api.github.com/users/joeyparrish/events{/privacy}","received_events_url":"https://api.github.com/users/joeyparrish/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":{"url":"https://api.github.com/repos/w3c/encrypted-media/milestones/2","html_url":"https://github.com/w3c/encrypted-media/milestones/VNext","labels_url":"https://api.github.com/repos/w3c/encrypted-media/milestones/2/labels","id":1365204,"number":2,"title":"VNext","description":"Those issues are editorial or substantive and will likely not get done (or cannot be done) within the V1 timeframe.","creator":{"login":"ddorwin","id":9738764,"avatar_url":"https://avatars.githubusercontent.com/u/9738764?v=3","gravatar_id":"","url":"https://api.github.com/users/ddorwin","html_url":"https://github.com/ddorwin","followers_url":"https://api.github.com/users/ddorwin/followers","following_url":"https://api.github.com/users/ddorwin/following{/other_user}","gists_url":"https://api.github.com/users/ddorwin/gists{/gist_id}","starred_url":"https://api.github.com/users/ddorwin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ddorwin/subscriptions","organizations_url":"https://api.github.com/users/ddorwin/orgs","repos_url":"https://api.github.com/users/ddorwin/repos","events_url":"https://api.github.com/users/ddorwin/events{/privacy}","received_events_url":"https://api.github.com/users/ddorwin/received_events","type":"User","site_admin":false},"open_issues":15,"closed_issues":0,"state":"open","created_at":"2015-10-20T00:51:44Z","updated_at":"2016-08-24T19:02:48Z","due_on":null,"closed_at":null},"comments":4,"created_at":"2016-07-27T18:05:06Z","updated_at":"2016-08-24T19:03:15Z","closed_at":null,"body":"As far as we've been able to tell, there's no inverse of the `waitingforkey` event to let an application know that the user agent is no longer waiting for a key.\r\n\r\nWe tried to do this with `keystatuseschange` events, supposing that a usable key status indicates that the browser is no longer waiting.  However, for content without a clear lead, we found two big problems with this.\r\n\r\n1. If the CDM just got a new key, but it's either the wrong key or there are still other keys needed, this is not the inverse of `waitingforkey`.  In most cases, though, another `waitingforkey` event fires after the `keystatuseschange` event.  Relying on an additional `waitingforkey` to convey that we are still waiting brings me to the second issue with this strategy...\r\n2. The `waitingforkey` event does not always fire strictly before the `keystatuseschange` event.  In some cases, we have all the keys we need, but the `keystatuseschange` event fires first, followed by a `waitingforkey` that is now obsolete.  I assume there is a race between the decoder thread dispatching `waitingforkey` and the CDM thread dispatching `keystatuseschange`.  At the application level, there's no clear way to tell when this has happened, so it looks as if the wrong keys have been obtained.\r\n\r\nSince using `keystatuseschange` as the inverse of `waitingforkey` seems to be dependent on timing, we have concluded that this is not a suitable solution.  We wanted to use `waitingforkey` as a diagnostic measure to tell application integrators when their license servers served the wrong keys, but without a matching event when the pipeline is unblocked, we will have to cut that feature.\r\n\r\nIs there an inverse event we can use today?  If not, could a future version of EME include one?"},"comment":{"url":"https://api.github.com/repos/w3c/encrypted-media/issues/comments/242173972","html_url":"https://github.com/w3c/encrypted-media/issues/284#issuecomment-242173972","issue_url":"https://api.github.com/repos/w3c/encrypted-media/issues/284","id":242173972,"user":{"login":"jdsmith3000","id":8323871,"avatar_url":"https://avatars.githubusercontent.com/u/8323871?v=3","gravatar_id":"","url":"https://api.github.com/users/jdsmith3000","html_url":"https://github.com/jdsmith3000","followers_url":"https://api.github.com/users/jdsmith3000/followers","following_url":"https://api.github.com/users/jdsmith3000/following{/other_user}","gists_url":"https://api.github.com/users/jdsmith3000/gists{/gist_id}","starred_url":"https://api.github.com/users/jdsmith3000/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jdsmith3000/subscriptions","organizations_url":"https://api.github.com/users/jdsmith3000/orgs","repos_url":"https://api.github.com/users/jdsmith3000/repos","events_url":"https://api.github.com/users/jdsmith3000/events{/privacy}","received_events_url":"https://api.github.com/users/jdsmith3000/received_events","type":"User","site_admin":false},"created_at":"2016-08-24T19:03:15Z","updated_at":"2016-08-24T19:03:15Z","body":"We don't plan to address this issue in EME V1."}}
{"actor":{"display_login":"jdsmith3000"}}