Define @@toStringTag on DOM objects

NEW
Unassigned

Status

()

Core
DOM
P2
normal
2 years ago
21 days ago

People

(Reporter: evilpie, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: btpp-followup-2016-07-05)

(Reporter)

Description

2 years ago
In ES6 Object.prototype.toString doesn't use a [[Class]] meta property anymore, so instead we have to add a Symbol.toStringTag property to all DOM prototype objects.
(Reporter)

Updated

2 years ago
Blocks: 1277801
Note that this will require actually solving the problem of value properties over Xrays in bindings...  We sort of have it for constants right now, but we don't support string-valued constants because rooting and which zone things are in become issues.  So we will need to think about this a bit.  Maybe extend IDL constants to allow a Value or a const char* or something.

Or just special-case this ID in the Xray code.  That might be best, actually.
How urgently do we need to do this?
Flags: needinfo?(evilpies)
Whiteboard: btpp-followup-2016-07-05
(Reporter)

Comment 3

2 years ago
I will try to implement @@toStringTag on the JS side in Firefox 50 (probably next week). After we implement this it would be nice to the DOM side as soon as possible, but as long as we keep the fallback code that I wrote everything should just keep working. (Object.prototype.toString on DOM object keeps working, but if some super insane new code expects DOM objects to have @@toStringTag that would fail)
It would be nice to finish the DOM side in the same release, especially because of Promises as they are still implemented there.
Flags: needinfo?(evilpies)
> It would be nice to finish the DOM side in the same release

The problem is that we still haven't decided what the DOM side behavior should be.  :(
(Reporter)

Comment 5

a year ago
This needs to be resolved at some point. Is this being discussed at whatwg or somewhere? If we want to self-host Object.prototype.toString (bug 1346546) we don't want to call into C++ to get the class name for all DOM objects.
In fairness, we could have a builtin, even inlinable, for getting the class name.  I agree it would be annoying.

This is not being actively discussed.  The current state is that Chrome ships one behavior, everyone else ships a different one, all the non-Chrome behaviors are not using @@toStringTag afaict, and Apple/Microsoft are not talking about this at all.

Updated

9 months ago
Priority: -- → P2
Bug 1424160 is going to add some infrastructure for doing this.
(Reporter)

Comment 8

21 days ago
Does that mean this is going to be fixed?
Well, so far I've made it somewhat easier to fix by doing various webidl parser and codegen legwork needed and using it for the generated webidl iterator prototypes.

Remaining work here:

1)  Set a toStringTag on all interfaces, not just the iterator interfaces.  This is basically one
    line of code in the webidl parser when creating the IDLInterface object.
2)  Probably need to fix Xrays to expose the @@toStringTag.  I didn't do that in bug 1424160
    because it didn't matter too much.

The big question, still, is whether we want the resulting behavior....
You need to log in before you can comment on or make changes to this bug.