1710433 - [META] Symbols as WeakMap property keys

Status: RESOLVED FIXED

(Core :: JavaScript Engine, enhancement, P3)

Description

[Yulia Startsev [:yulia] OOO until July 2026]

Currently at stage 2

Comment 1

[Alexandre Folle de Menezes]

Proposal now in Stage 3

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

I have the following test code:

const map = new WeakMap();
const key = Symbol();
map.set(key, 42);

It throws error:

Uncaught TypeError: WeakMap key Symbol() must be an object or an unregistered symbol

However, it works fine on both Chrome and Safari, which means there can be compatibility issue arises from it, and the behavior here is inconsistent with this error message, which is very confusing.

Comment 3

[Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi]]

(In reply to Xidorn Quan [:xidorn] UTC+11 from comment #2)

However, it works fine on both Chrome and Safari, which means there can be compatibility issue arises from it, and the behavior here is inconsistent with this error message, which is very confusing.

Have you turned on the pref "javascript.options.experimental.symbols_as_weakmap_keys" ?
It is still off by default.

Comment 4

[Xidorn Quan [:xidorn] UTC+10]

(In reply to Yoshi Cheng-Hao Huang [:allstars.chh][:allstarschh][:yoshi] from comment #3)

Have you turned on the pref "javascript.options.experimental.symbols_as_weakmap_keys" ?
It is still off by default.

No. Should there be a bug tracking this pref change? Also should we have the error thrown adapt to the availability of this feature, and potentially even mention the tracking bug?

Comment 6

[andseier]

Any updates on this one? I wanted to start using Symbols as WeakMap keys, but I just noticed that it breaks in FF when I test. Thanks!

Comment 7

[csvn.dev]

I think when using "lib": ["es2023"] with Typescript, the es2023.collection is only unsupported in Firefox now. It would be great if this last "ES2023" feature was supported in Firefox as well.

Comment 8

[Will Medina [:willyelm]]

Hi Tom

Since we keep meta bugs open to track future spec changes and issues, should we move the webcompat webcompat:risk-moderate whiteboard tag to Bug 1863140?

Comment 9

[Thomas Wisniewski [:twisniewski]]

Yes, definitely. I was intending to revisit meta-bugs which I've marked with risk scores ASAP, to move the scores as appropriate to their sub-bugs. I'll move this one as you suggested now (and mark that bug as parity-chrome and -safari, since that seems to be the case).

Comment 10

[Xidorn Quan [:xidorn] UTC+10]

Hey Will, is there any bug tracking enabling this feature itself? I believe not enabling symbols as weak key itself has webcompat implications. This is especially true given that TypeScript is shipping this in their declaration for es2023.collection as mentioned in comment 7, and if devs use that as a guide without checking compatibility with Firefox, things can fall dramatically.

Personally I have seen a few times internally in my current company (Canva) that someone tries to use symbol as weak key. Those instances are either stopped by review, or caught in staging before reaching production. But this isn't a reliable way to catch such an issue, so the sooner we can close this webcompat gap the better.

Comment 11

[Jan de Mooij [:jandem]]

Will is no longer at Mozilla so I'm redirecting the NI.

Comment 12

[Dan Minor [:dminor]]

I filed Bug 1966745 to track shipping this.

Comment 13

[csvn.dev]

Bug 1966745 is resolved, and it works great when I tried this in Nightly Firefox! 🎉

const wm = new WeakMap();
const s = Symbol();
wm.set(s, '🎉');
console.log(wm.get(s));
-> 🎉

Does the support table on MDN for WeakMap need to be updated manually, to show that this feature is supported in a pre-release version (similar to Atomits.waitAsync())? Or is the table only updated when a version reaches the Beta channel and not Nightly?

Can this issue be closed, or does it need to reach Beta/Stable before closing?

Comment 14

[Jon Coppeard (:jonco)]

This has shipped so closing the bug.