Can FrozenArray<T> be used for a mutable attribute?

[foolip]

https://heycam.github.io/webidl/#idl-frozen-array
https://heycam.github.io/webidl/#es-frozen-array

file:///usr/local/google/home/foolip/spec/mediasession/index.html#the-mediametadata-interface has this:

[Constructor(optional MediaMetadataInit init), Exposed=Window]
interface MediaMetadata {
  attribute DOMString title;
  attribute DOMString artist;
  attribute DOMString album;
  attribute FrozenArray<MediaImage> artwork;
};

Does that work? I can't see anything in Web IDL that explicitly disallows it, but also don't understand what would happen if assigning to artwork.

@xxyzzzq @mounirlamouri

[tobie]

I can't see anything in Web IDL that explicitly disallows it, but also don't understand what would happen if assigning to artwork.

From the mediasession spec, it seems to set an internal slot when setting, which seems fine to me. The call to SetIntegrityLevel in step two of the "create a frozen array" abstract operation, freezes the properties of the array, not the artwork attribute of the object implementing the MediaMetadata interface.

@domenic can you confirm?

[foolip]

This is the only mutable FrozenArray<T> attribute in Blink, and perhaps the first in any spec, so I thought it best to check if behavior like this is fine:

artwork = [];
metadata.artwork = artwork;
assert_not_equals(metadata.artwork, artwork)
assert_equals(metadata.artwork, metadata.artwork)

[tobie]

Oh, sorry. Misunderstood the question.

Yes, from an API design perspective, I agree this looks terrible and counter intuitive.

[bzbarsky]

This is the only mutable FrozenArray attribute in Blink, and perhaps the first in any spec

As far as I'm aware, that's correct.

so I thought it best to check if behavior like this is fine

The behavior you describe is the currently specced behavior, for what it's worth. Also note:

var artwork = [];
metadata.artwork = artwork;
artwork = metadata.artwork;
metadata.artwork = artwork;
assert_not_equals(metadata.artwork, artwork);

Unfortunately there aren't really better options here, which is why FrozenArray is specced the way it's specced.

[foolip]

OK, sounds like this is not an oversight, thanks for confirming! I'll link to here from Intent to Ship: MediaSession API.

[bzbarsky]

I mean, I guess we can have the general discussion about whether we should allow writable FrozenArray attributes or whether they lead to bad API.

In this case, it's certainly leading to a bad spec, because the way the setter for this attribute is defined is:

On setting, it MUST run the convert artwork algorithm with the new value as input, and set the MediaMetadata's artwork images as the result if it succeeded.

OK, but what is the new value? The new value is the output of the steps at https://heycam.github.io/webidl/#es-frozen-array (why do we not have a #es-to-frozen-array?) and hence is an ES Array object that has been frozen. OK, so we call into https://wicg.github.io/mediasession/#convert-artwork-algorithm and it does "for each entry in input's artwork" which is really not defined at all (in multiple ways; I think the spec editor got confused about what the type of the incoming thing is). This spec would be much better served by having a sequence there as the input; it would be harder to screw up.

[bzbarsky]

I filed w3c/mediasession#176 on the spec being confused.

[foolip]

Thanks @bzbarsky! I guess I'll close this issue, if someone wants to avoid this pattern on the web platform please shout soon.