Error cause underspecified in Structured Clone algorithm

[WebReflection]

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]

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]

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]

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]

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

[WebReflection]

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?