1561357 - Make DOMException [Serializable]

Status: RESOLVED FIXED

(Core :: DOM: postMessage, enhancement, P3)

Description

[Boris Zbarsky [:bzbarsky]]

Spec change: https://github.com/heycam/webidl/pull/732

Tests: https://github.com/web-platform-tests/wpt/pull/17095

Comment 1

[Kagami [:saschanaz]]

Attachment: Bug 1561357 - Implement [Serializable] for DOMException r=mgaudet!,sfink!

Skipping stack serialization here as

• it's optional per the spec
• no WPT test exists
• Chrome doesn't support it either
• not sure how it's usable when transferred to other domain.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0f9f2acf6e13
Implement [Serializable] for DOMException r=smaug,sfink

Comment 3

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/0f9f2acf6e13

Comment 4

[Hamish Willee]

FF101 docs for this can be tracked in https://github.com/mdn/content/issues/15638

What were you thinking of for a release note? Or to put it more specifically, why is it useful to be able to serialize a DOMException? I mean I think this allows you to call StructuredClone() on an exception, but not sure when and why you would want to - is there a specific/real use case??

My understanding of this is that it means you can now

• serialize DOMException objects, which will effectively allow the name and message attributes to be encoded/decoded back to an exception object
  • other attributes may be serialized according to spec but none others are done in FF (e.g. stack)
• I think the main implication is that you can now call structuredClone() to clone an exception.
  • But it isn't also transferrable.

From a docs point of view the things I think we'd do from what I know are:

• Browser-compat data: - this appears to be a compatibility change (right?), so probably add it to BCD for FF101. Do you happen to know when Chrome supported this?
• Add a note that it is serializable to DOMException. Perhaps note that this will be name and message and may be other data.
• Add DOMException to the list: The structured clone algorithm > Supported types

Does that sound reasonable?

Some other questions that might help me:

• Does this serialization affect/get made use of by anything other than structuredClone()? I mean, for example, might this now allow you to call toJson on a DOMException to get the serialized format when you couldn't before?
• Do you know when Chrome started supporting this as serializable?

Comment 5

[Kagami [:saschanaz]]

(In reply to Hamish Willee from comment #4)

What were you thinking of for a release note? Or to put it more specifically, why is it useful to be able to serialize a DOMException? I mean I think this allows you to call StructuredClone() on an exception, but not sure when and why you would want to - is there a specific/real use case??

Per https://github.com/whatwg/html/issues/4268 this was introduced mainly to let stream objects transferred from different realms pass the JS errors to the current realm. (This bug is only about DOMException as JS errors are not covered yet)

This also means anything that works in parallel can now pass the DOMException as-is, rather than manually crafting JSON data to signal there was an error.

Does that sound reasonable?

Yup, looks good.

• Does this serialization affect/get made use of by anything other than structuredClone()? I mean, for example, might this now allow you to call toJson on a DOMException to get the serialized format when you couldn't before?

postMessage() also uses serializable, so devs can now pass errors across workers. There's no toJSON though, that's a different thing and it's not in the spec.

• Do you know when Chrome started supporting this as serializable?

https://bugs.chromium.org/p/chromium/issues/detail?id=970079, but I don't have the exact version number.

Comment 6

[Hamish Willee]

Thanks very much for your help @Kagami. I have updated as discussed, including a topic on serializable objects to complement the one on transferable objects.

A "related" question (or two), if you have time:

• Am I correct to assume that in order to be used with the structuredClone() an object must be serializable? I.e. I could move Structured_clone_algorithm > supported types to serializable objects if I wanted?
• Do you see any value in having a separate document for The structured clone algorithm and structuredClone? We do say that postMessage uses the structured clone algorithm rather than it uses structuredClone, which might be one reason. I'd like to merge them if it makes sense to do so.

Comment 7

[Kagami [:saschanaz]]

• Am I correct to assume that in order to be used with the structuredClone() an object must be serializable? I.e. I could move Structured_clone_algorithm > supported types to serializable objects if I wanted?

Both transferable and serializable objects can use structuredClone, with { transfer: [...] } option if the former.

An interface can be either transferable, serializable, or both (e.g. https://html.spec.whatwg.org/multipage/imagebitmap-and-animations.html#imagebitmap).

• Do you see any value in having a separate document for The structured clone algorithm and structuredClone? We do say that postMessage uses the structured clone algorithm rather than it uses structuredClone, which might be one reason. I'd like to merge them if it makes sense to do so.

postMessage does not use structuredClone. structuredClone per the spec serializes and then immediately deserializes (or transfer/receive transfer) in the same context, but in postMessage those two normally happens in two different contexts. I'd keep them separate.