HTML integration for "Error Stack Accessor" TC39 Proposal

[ljharb]

Replace the non-normative "should" language about serializing "interesting accompanying data" with normative steps that explicitly serialize and deserialize the stack trace of Error objects during structured cloning.

In StructuredSerializeInternal, the stack trace is obtained as an implementation-defined string and included in the serialized record as [[Stack]].

In StructuredDeserialize, the Error object is created with a [[Stack]] internal slot, which is set to an implementation-defined value representing the stack trace from the serialized record. This ensures the Error.prototype.stack accessor continues to work properly on deserialized errors.

The bibliography is updated to reference both the Error Stack Accessor and Error Stacks proposals.

This is the HTML integration PR for tc39/proposal-error-stack-accessor.

See tc39/proposal-error-stack-accessor#9 and tc39/proposal-error-stack-accessor#8, as well as whatwg/webidl#1578

• At least two implementers are interested (and none opposed):
  • …
  • …
• Tests are written and can be reviewed and commented upon at:
  • Add WPT tests for Error Stack Accessor proposal web platform integration web-platform-tests/wpt#58397
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): …
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): …
• Corresponding HTML AAM & ARIA in HTML issues & PRs:
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/references.html ( diff )
/structured-data.html ( diff )

[nicolo-ribaudo]

There is other "interesting data" that should still be copied over, such as https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/lineNumber.

[ljharb]

@nicolo-ribaudo should that be called out, or left implementation-defined?

[nicolo-ribaudo]

The old spec text was:

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

You replaced it with explicit steps to copy stack, but I think you should also keep including

User agents should attach a serialized representation of any interesting accompanying data which are not yet specified to serialized.

[annevk]

And yeah, let's preserve the "interesting accompanying data" step as well. Hopefully one day that won't be needed anymore.

[annevk]

This needs rewrapping.

[annevk]

xref implementation-defined. Although, can it literally be anything? We already serialized it to a string. Can it stay a string or do some implementations deserialize to an Array or Object? It would be nice if only one side had to be implementation-defined and we could at least agree on the value type.

[ljharb]

The user-visible value is always a string, but implementations can store any data structure they like there, and they will want to if https://github.com/tc39/proposal-error-stacks advances.

[annevk]

But then let’s just serialize as an implementation-defined string and return that as-is here? Alternatively I suppose we could have implementation-defined on both sides but then we don’t have to require a string when serializing, but do need to require that here.