Closed Bug 1561357 Opened 5 years ago Closed 2 years ago

Make DOMException [Serializable]

Categories

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

enhancement

Tracking

()

RESOLVED FIXED
101 Branch
Tracking Status
firefox69 --- wontfix
firefox101 --- fixed

People

(Reporter: bzbarsky, Assigned: saschanaz)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

Type: defect → enhancement
Priority: -- → P3
Component: DOM: Core & HTML → DOM: postMessage
Blocks: 1659025
Assignee: nobody → krosylight
Status: NEW → ASSIGNED
Keywords: dev-doc-needed

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.
Attachment #9272148 - Attachment description: Bug 1561357 - Implement [Serializable] for DOMException r=mgaudet!,smaug! → Bug 1561357 - Implement [Serializable] for DOMException r=mgaudet!,sfink!
Pushed by krosylight@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/0f9f2acf6e13
Implement [Serializable] for DOMException r=smaug,sfink
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 101 Branch
Blocks: 1556604
No longer depends on: 1556604
Regressions: 1766647

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?
Flags: needinfo?(krosylight)

(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.

Flags: needinfo?(krosylight)

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:

Flags: needinfo?(krosylight)

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.

Flags: needinfo?(krosylight)
Blocks: 1777321
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: