The freezing in the artwork getter is broken
Opened this issue · 3 comments
In https://w3c.github.io/mediasession/#dom-mediametadata-artwork there is this step:
Call Object.freeze on image, to prevent accidental mutation by scripts.
But image is an IDL dictionary here, not a JS value, so you can't call Object.freeze
on it.
Maybe this means to say that you convert the dictionary to a JS object, then freeze it? That would be a viable option if this is the defined behavior, but then the artwork
attribute should return FrozenArray<object>
, because when you're creating the FrozenArray
it's done from a list of objects, not a list of MediaImage
dictionaries.
How does this spec imagine people change metadata? It would help if the examples showed this.
Here's what I get in Chrome:
navigator.mediaSession.metadata = new MediaMetadata({artist:"Ƭ̵̬̊", artwork:[{src:"A.png"}]})
navigator.mediaSession.metadata.artist = "Prince"
navigator.mediaSession.metadata.artwork[0].src = "B.png"
navigator.mediaSession.metadata.artist // Prince
navigator.mediaSession.metadata.artwork[0].src // "http://example.com/A.png"
artwork[0].src
was not updated. That seems to spec and broken. How do I change artwork?
The other thing that's odd is there's no way to add or remove artwork. How do I do that?
If things are meant to be changed solely through the constructor, I'd make MediaImage
an interface, and all attributes readonly
.
Or make MediaImage
an interface and remove the freezing, and support
navigator.mediaSession.metadata.artwork[0].src = "B.png"
So there are two different issues here:
- By the behavior defined in the current spec, the
artwork
inMediaMetadata
must beFrozenArray<object>
rather thanFrozenArray<MediaImage>
, so the item in theartwork
can be frozen. - We probably should make
MediaImage
be aninterface
instead ofdictionary