1057699 - Structured cloning should support symbols

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, enhancement)

Description

[Jeff Walden [:Waldo]]

In order to send symbols as values through postMessage and similar, symbols need to be able to be structured-cloned.  This should be a relatively short, but not ridiculously trivial, first bug.

You'll want to be aware of the data that a symbol encapsulates/represents.  I believe this comes down to 1) the description associated with it, 2) whether the symbol is or isn't registered, and 3) whether it's one of the well-known symbols.

You'll then need to add code to both read and write symbols, in js/src/vm/StructuredClone.cpp.  There's probably a little bit of design work that'll have to go into this -- ask in #jsapi if you're unsure how to proceed on this point, or comment here.

Finally, you'll want to write some tests to make sure your code works.  js/src/jit-test/tests/structured-clone/ may be a good place to look to see how to write these tests, and where to add them.

This should be nearly all the information needed to write a patch for this.  If you have questions, comment here or head onto #jsapi on Mozilla's IRC servers and ask questions there.

Comment 1

[Jeff Walden [:Waldo]]

A minor complication is that because Symbol("foo") !== Symbol("foo"), symbols will have to be hooked into the don't-duplicate-serialize mechanics in structured cloning.  These are probably a little more complicated.  We already have code handling this for objects, to possibly either that can be repurposed, or it can be generalized to objects-or-symbols.  Again, questions to #jsapi.

Comment 2

[Iskandar Rafikov]

I can work on this bug.

Comment 3

[Keith Yeung [:KiChjang]]

AIUI, StructuredClone is specified here https://html.spec.whatwg.org/multipage/infrastructure.html#structuredclone, and in Step 4, it explicitly states that if the input value is of the Symbol type, it should throw an DataCloneError. Are we wilfully veering off spec here?

Assuming that we are to deviate from the spec, I can't really seem to find the relevant data for Symbol in its struct definition except for its description. Is there a special function that I need to call in order to extract data about 1) whether it's registered or not and 2) whether it's one of the well-known symbols? Also, is a Symbol an object, or is it its own type?

Comment 4

[Jeff Walden [:Waldo]]

No proposal to deviate from spec.  If the spec doesn't support this, changing it so it does would be the first step.  I think my semi-assumption was that it would eventually change to support some classes of symbol.

That said, this is only really supportable for |Symbol.for(...)| symbols, which may not be enough to make this useful.  If spec-upstream were sure it wasn't worth supporting only registered symbols, this would be WONTFIX.  But I don't know whether they've done that or not.  (And I'm not sure whether ECMA-262 has spec hooks that the structured clone spec could call, if it wanted to do this, to determine whether a symbol is a registered symbol or not.)

Comment 5

[Keith Yeung [:KiChjang]]

Attachment: Bug1057699.patch

Comment 6

[Keith Yeung [:KiChjang]]

Oh, and sorry, I forgot to comment here saying that I'm looking into this.

Comment 7

[Jeff Walden [:Waldo]]

Comment on attachment 8796822 [details] [diff] [review]
Bug1057699.patch

Review of attachment 8796822 [details] [diff] [review]:
-----------------------------------------------------------------

Spec right now doesn't say symbols of any sort should be clonable, so we can't take this right now.  If you want to get this changed, you should go to WHATWG first and ask there, per comment 4 (which also should have noted the builtin symbols -- Symbol.iterator and so on -- should be considered for being supported for cloning).

Comment 8

[Keith Yeung [:KiChjang]]

Filed https://github.com/whatwg/html/issues/1862.

Comment 9

[Keith Yeung [:KiChjang]]

I think this should be closed as a WONTFIX, give the reply from WHATWG.

Comment 10

[Matthew Gaudet (he/him) [:mgaudet]]

I agree with Keith, barring https://github.com/whatwg/html/issues/1862 getting re-opened. (Tidying https://codetribute.mozilla.org/projects/jseng)