Are interfaces inheriting from [Seralizable]/[Transferable] interfaces required to have their own steps?

[saschanaz]

https://html.spec.whatwg.org/multipage/structured-data.html#serializable-objects

For a given platform object, only the object's primary interface is considered during the (de)serialization process. Thus, if inheritance is involved in defining the interface, each [Serializable]-annotated interface in the inheritance chain needs to define standalone serialization steps and deserialization steps, including taking into account any important data that might come from inherited interfaces.

https://html.spec.whatwg.org/multipage/structured-data.html#transferable-objects

For a given platform object, only the object's primary interface is considered during the transferring process. Thus, if inheritance is involved in defining the interface, each [Transferable]-annotated interface in the inheritance chain needs to define standalone transfer steps and transfer-receiving steps, including taking into account any important data that might come from inherited interfaces.

Does this mean any inheriting interfaces must always define their own steps? Should they also explicitly have the extended attribute too?

For now not all sub-interfaces follow the superclasses' extended attribute; for example FileSystemWritableFileStream does not have [Transferable], does not have the transfer steps, and Blink does not support the transfer of them while it does for WritableStream.

[annevk]

Yes, each interface needs its own extended attribute and steps. See https://w3c.github.io/FileAPI/ for an example and #5036 for context.

Has the time come to revisit this design or do we simply need to squash some bugs?

[saschanaz]

Sounds like a new IDL validation rule in webidl2.js can help at least to force the extended attribute.

[annevk]

We probably first have to decide what we want to enforce? There are no guidelines around this currently, except that without the attribute the interface cannot be serialized or transferred.

[saschanaz]

Oh, my question was about that, whether subinterfaces are enforced to have the steps/attribute or not.

[saschanaz]

A bit more context: Gecko has a bug that transfers FileSystemWritableFileStream as a WritableStream: https://bugzilla.mozilla.org/show_bug.cgi?id=1832166

const directory = await navigator.storage.getDirectory();
const handle = await directory.getFileHandle("handle", { create: true });
const writable = await handle.createWritable({});
structuredClone([writable], { transfer: [writable] }); // becomes [WritableStream], oops.

But perhaps that can be useful? Marking FileSystemWritableFileStream itself as [Transferable] would require significant work but can we allow such subinterfaces to be transferred as the base interface?

[annevk]

The current contract is that anything not annotated will throw.

If you want FileSystemWritableFileStream to not throw you would have to get it annotated. You can then decide what kind of behavior you want. Full or minimal. (I would expect we don't want it until we can make it fully useful, but I haven't looked at this in detail. Either way, more of a discussion for whatwg/fs than whatwg/html.)

Then, if we have a lot of interface subclasses that also need to be annotated with steps that are identical or match up well with their super, we could consider making changes to the HTML Standard to make the overall setup less involved.

[saschanaz]

I guess you are right, filed whatwg/fs#119