Bug 192815 - [EME] MediaKeySystemConfiguration distinctiveIdentifier and persistentState should default to optional
Summary: [EME] MediaKeySystemConfiguration distinctiveIdentifier and persistentState s...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Xabier Rodríguez Calvar
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-12-18 11:05 PST by Xabier Rodríguez Calvar
Modified: 2018-12-19 23:20 PST (History)
4 users (show)

See Also:

Attachments
Patch (1.87 KB, patch)
2018-12-18 11:17 PST, Xabier Rodríguez Calvar 		no flags Details | Formatted Diff | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Xabier Rodríguez Calvar 2018-12-18 11:05:49 PST 
[EME] MediaKeySystemConfiguration distinctiveIdentifier and persistentState should default to optional
Comment 1 Xabier Rodríguez Calvar 2018-12-18 11:17:18 PST 
Created attachment 357585 [details]
Patch
Comment 2 WebKit Commit Bot 2018-12-19 00:56:03 PST 
Comment on attachment 357585 [details]
Patch

Clearing flags on attachment: 357585

Committed r239373: <https://trac.webkit.org/changeset/239373>
Comment 3 WebKit Commit Bot 2018-12-19 00:56:04 PST 
All reviewed patches have been landed.  Closing bug.
Comment 4 Radar WebKit Bug Importer 2018-12-19 00:57:28 PST 
<rdar://problem/46835043>
Comment 5 Darin Adler 2018-12-19 23:20:01 PST 
Comment on attachment 357585 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=357585&action=review

> Source/WebCore/ChangeLog:11
> +        https://www.w3.org/TR/encrypted-media/#dom-mediakeysystemconfiguration
> +        says that distinctiveIdentifier and persistentState default to
> +        optional. Our implementation does not define a default leaving it
> +        to the first option of the enum, which currently is Required.

Actually, I think it was worse than that before. Our implementation was not initializing the field, which doesn’t guarantee what it will be initialized to! We were getting a 0, but that wasn’t guaranteed.