Skip to content

Error cause underspecified in Structured Clone algorithm #11321

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
WebReflection opened this issue May 20, 2025 · 5 comments
Open

Error cause underspecified in Structured Clone algorithm #11321

WebReflection opened this issue May 20, 2025 · 5 comments
Labels
topic: serialize and transfer

Comments

@WebReflection
Copy link
Contributor

What is the issue with the HTML Standard?

In step 17 of StructuredSerializeInternal it's mentioned that, beside type, message and name (not super useful for developers):

User agents should attach a serialized representation of any interesting accompanying data which are not yet specified, notably the stack property, to serialized

Now, the base Error class has only 2 fields: message and cause.

The MDN description for cause is:

It is used when catching and re-throwing an error with a more-specific or useful error message in order to still have access to the original error.

Accordingly, you can imagine my disappointment when I've realized that while Chrome/ium and Firefox clone that field too, WebKit doesn't clone it and it's impossible to attach relevant Error details to anything that is going to be forwarded via postMessage(thatError).

The test is pretty simple:

console.assert(
  structuredClone(
    new Error('reason', { cause: 123 })
  ).cause === 123
);

This fails in WebKit but it looks to me that field must be forwarded for cross platform, cross browser, and cross realm compatibility sake, so that having it unspecified as MUST like it is for message, type and name feels like a bug/hazard when better error messages, propagation or handling, is desired in any program that works on the main or any other worker based thread.

/cc @rniwa here because both WebKit and Bun (or anything JSC based) is making it impossible for us to provide better errors when WASM non-blocking code generates errors within Workers (Service, Shared, or regular).

Thanks in advance for considering a fix to this part, it's the only field that currently gives developers any extra power to attach more to errors and having it unusable due lack of cross engine compatibilities feels like a huge mistake/limitation.
@domenic
Copy link
Member

domenic commented May 20, 2025

This was attempted in #5749, but we got stuck. At this point the latest plan is for @syg to move structured cloning into the JavaScript specification, so that we stop missing things added to the ECMAScript types. Until that work happens, you can consider the set of properties cloned to be frozen to the set of properties that are in the JS spec as of ~2020. (So, Chromium and Firefox are actually not conformant to the current spec, which does not allow copying cause.)

WebReflection added a commit to WebReflection/serialization-registry that referenced this issue May 20, 2025
@WebReflection
Use Map instead of Error due WebKit/JSC issue.
99b708f 
  * see whatwg/html#11321

Also added limitations in the README to explain that currently
the logic is kept minimal and as simple as possible to cover
most common/desired use cases without compromising too much
performance (via overly crawling all sort of primitive types).
@WebReflection
Copy link
Contributor Author

First of all, thanks for the answer!

That MR looked great to me but there seems to be a lot going on ... meanwhile, both Firefox and Chromium implemented the cloning of cause which is not a random attached property, it's actually the only extra specified field of the Error base class ... is that what you mean when you say that's an ECMAScript thing and if more happens in there (i.e. stack) it shouldn't be WHATWG responsibility to keep updating this part of the specs?

In TC39 I've been told Structured Clone is WHATWG responsibility and it was indeed confusing to me, but seeing all sort of native Web (only?) classes as part of the algorithm made me wonder where this spec should be moved forward 'cause it looks like "no matter where" there will be back and forward alignment between these two spaces.

Chromium and Firefox are actually not conformant to the current spec, which does not allow copying cause.

By no mean I want these two browsers to remove that wonderful (and expected) non-specified feature but how difficult could it be to just make the status-quo official so that WebKit can follow at least that cause gotcha and implement it same way Chrome and Firefox did?

Or is it even possible/desired? 'cause moving this over ECMAScript and then start fresh all issues around this algorithm will take a huge amount of time and a lot of discussions will be lost in the process ... but I understand current state is not ideal at all, I am just worried nothing will happen for years if we move this essential part of the Web somewhere else at this point in time.

@evilpie
Copy link
Member

evilpie commented May 20, 2025

I think Step 17.6. of StructuredSerializeInternal explicitly allows us to serialize additional data:

User agents should attach a serialized representation of any interesting accompanying data which are not yet specified, notably the stack property, to serialized.

@domenic
Copy link
Member

domenic commented May 20, 2025

Step 17.6 only allows you to attach not yet specified data. You're not allowed to attach specified data, such as cause.

@WebReflection
Copy link
Contributor Author

fair enough ... but ... if cause was known as field and not something new introduced after 2020, why can't we amend/extend requirements for the Error instances to provide and clone cause too when explicitly attached?

I feel like cause would solve dozen problems already without needing to "move the world" to TC39 shoulders (or at least before that as only one browser is missing the train there).

Accordingly, the OP intent is to not change anything but cause field in the current algorithm so that nobody except eventually the WebKit team needs to comply with that amend and we can use, until things are settled in a way or another, a field that helps circumventing every limitation we have right now with errors, no matters where these come from.

Is this a possibility?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic: serialize and transfer
Milestone
No milestone
Development

No branches or pull requests
3 participants
@WebReflection @evilpie @domenic
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy