W3C home > Mailing lists > Public > public-html-media@w3.org > January 2013

[Bug 20688] New: Provide more details on when keyadded should be fired

From: <bugzilla@jessica.w3.org>
Date: Wed, 16 Jan 2013 23:16:52 +0000
To: public-html-media@w3.org
Message-ID: <bug-20688-5436@http.www.w3.org/Bugs/Public/>

            Bug ID: 20688
           Summary: Provide more details on when keyadded should be fired
    Classification: Unclassified
           Product: HTML WG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Encrypted Media Extensions
          Assignee: adrianba@microsoft.com
          Reporter: ddorwin@google.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-media@w3.org

when renewing a license?

The January 14, 2013 version of the spec says:
  For each individual key in key, store the individual key... Let did store key
be true.
  If did store key is true, queue a task to fire a simple event named keyadded
at the MediaKeySession object.

This works fine for a simple scenario, but is ambiguous for other scenarios.
More generally, what is the purpose of this event? (It originally enabled the
app to call play() before responsibility for resuming playback was moved to the

Possible purposes:
 1) New (unique) key added.
 2) New key info added, possibly for an existing key.
 3) update() operation completed successfully, regardless of whether it
involved addition of a key. (This would likely result in renaming this method.)

Example questions to address:
 * Should keyadded be fired once for each key that is added (if a license
contains multiple keys)?
 * Should keyadded be fired if the key was already known?
 * Should keyadded be fired if the license/key policy was updated?
 * Should keyadded be fired for successful completion of update() when no
further messages need to be sent to the server?

You are receiving this mail because:
You are on the CC list for the bug.
Received on Wednesday, 16 January 2013 23:16:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:58 UTC