Implement FrozenArray in webidl




2 years ago
9 months ago


(Reporter: jib, Unassigned)




Firefox Tracking Flags

(firefox46 affected)



To implement RTCTrackEvent [1], we should ideally use FrozenArray:

  // TODO: Use FrozenArray once available.
  //  readonly        attribute FrozenArray<MediaStream> streams;


  [Frozen, Cached, Pure]
  readonly        attribute sequence<MediaStream> streams;

Is FrozenArray now considered stable enough?  It seems fine to me, but have we had any feedback from the other browser vendors?

Note that the workaround in comment 0 will in fact produce identical semantics to FrozenArray, and in fact the implementation plan for this should probably be to just desugar FrozenArray, at least for attributes, so consumers are not forced to deal with JS arrays.
Flags: needinfo?(cam)
The only feedback I've seen (which you have too) is in where Travis still doesn't seem convinced.  Really the only feasible alternative is to use non-frozen arrays, don't create new instances when we need to change their contents, define carefully how updates to arrays work, and for the platform object that vends such such arrays not to use their contents as the source of truth.  The two competing concerns of "live lists are bad" and "object identity from getter should be preserved" are fundamentally at odds.

At this point I don't know what can be done beyond trying it out.
Flags: needinfo?(cam)
We can try it out in practice using said workaround....
When this is implemented, it should be documented here:
Keywords: dev-doc-needed
This is needed for the vibrate and actions attributes of Notifications:
Blocks: 1273641, 1225110
Not really blocking anything; see comment 0.  We already support this, just with an uglier syntax.
Flags: needinfo?(overholt)
Oops, sorry.
No longer blocks: 1225110, 1273641
Flags: needinfo?(overholt)
See Also: → bug 1284357

Comment 8

11 months ago
Note, I have a spec that requires `[SameObject] FrozenArray<>`.  [Pure] seems incompatible with [SameObject].

See ancestorOrigins attribute here:
> Note, I have a spec that requires `[SameObject] FrozenArray<>`.  [Pure] seems incompatible with [SameObject].

Well, our IDL parser rejects, because [SameObject] is a stronger claim than [Pure].

Since it's a stronger claim, you can just replace "Pure" with "SameObject" in the workaround annotations.


1)  We allow a sequence<> type for an attribute if the attribute is [Cached].  See

2)  [Cached] attributes must be [Pure] or [Constant] or [SameObject], as documented in the same place.
> because [SameObject] is a stronger claim than [Pure]

Which means claiming _both_ is nonsense and you're probably doing something wrong if you claim both...
You need to log in before you can comment on or make changes to this bug.