[DO NOT LAND] Set @@toStringTag for DOM object prototypes

[DO NOT LAND] Set @@toStringTag for DOM object prototypes

[DO NOT LAND] Requires "--harmony-tostring" support enabled.

The behavior change is that ({}).toString.call() on a
prototype will return "[object HTMLElement]" rather than
"[object Object]". This also allows us to remove
calling SetClassName() on each instance, bringing the
DOM and ES6 closer together.

This is a willful violation of WebIDL, which explicitly
requires a @@toStringTag property on each *instance*
(e.g. "HTMLElement") and on each prototype
(e.g. "HTMLElementPrototype"). We do not believe
there is a web compat issue since Blink has never returned
a particular string, but we'll need to watch closely.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244

BUG=239915

[jsbell, 2015-03-17 23:57:14]

Just throwing this up to see what the bots say - we shouldn't even think about
landing before --harmony-tostring is "shipped" by v8.

At a minimum:
* Wait for harmony-tostring to ship
* Needs tests
* Need to understand and remove/replace result->SetClassName() call from 
{{v8_class}}Constructor::domTemplate() in templates/interface.cpp
* Need to understand and remove/replace shadowTemplate->SetClassName() call in
wrapInShadowTemplate()

[jsbell, 2015-03-19 16:52:19]

On 2015/03/17 23:57:14, jsbell wrote:
> * Need to understand and remove/replace result->SetClassName() call from 
> {{v8_class}}Constructor::domTemplate() in templates/interface.cpp

Replaced with setting @@toStringTag on the instanceTemplate there. That path is
used for HTML elements that can be constructed directly, e.g. `new Image`, as
opposed to `document.createElement('img')`. I don't yet understand the need for
the distinction, but we have good test coverage!

[haraken, 2015-03-19 23:30:55]

haraken@chromium.org changed reviewers:
+ haraken@chromium.org

[haraken, 2015-03-19 23:30:56]

LGTM

https://codereview.chromium.org/1017733003/diff/40001/Source/bindings/templat...
File Source/bindings/templates/interface_base.cpp (right):

https://codereview.chromium.org/1017733003/diff/40001/Source/bindings/templat...
Source/bindings/templates/interface_base.cpp:475:
instanceTemplate->Set(v8::Symbol::GetToStringTag(isolate),
v8AtomicString(isolate, "{{interface_name}}"));

Just to confirm: What is the interface_name of WebKitTransitionEvent?
WebKitTransitionEvent is an alias of TransitionEvent, and I'm curious how the
alias is handled.

https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...

[jsbell, 2015-03-19 23:43:21]

On 2015/03/19 23:30:56, haraken wrote:
> Just to confirm: What is the interface_name of WebKitTransitionEvent?
> WebKitTransitionEvent is an alias of TransitionEvent, and I'm curious how the
> alias is handled.
> 

I'll take a look.

If you review the bug, we've got concerns about using @@toStringTag exactly like
this and are pushing back on WebIDL.

But these are all great questions to answer and I'll spin up some tests.

[jsbell, 2015-03-21 00:06:00]

PS#4 adds a dedicated test fast/js/webidl-class-strings.html - doesn't cover
everything in the spec yet, though. Iterators aren't quite right, but the spec
seems sketchy there anyway.

One interesting finding:

(new Image).__proto__ === document.createElement('img').__proto__

This actually returns false in Chrome - !?!?!?

[arv (Not doing code reviews), 2015-06-02 22:25:26]

On 2015/03/21 00:06:00, jsbell wrote:
> PS#4 adds a dedicated test fast/js/webidl-class-strings.html - doesn't cover
> everything in the spec yet, though. Iterators aren't quite right, but the spec
> seems sketchy there anyway.
> 
> One interesting finding:
> 
> (new Image).__proto__ === document.createElement('img').__proto__
> 
> This actually returns false in Chrome - !?!?!?

https://code.google.com/p/chromium/issues/detail?id=310776

[arv (Not doing code reviews), 2015-06-02 22:27:07]

arv@chromium.org changed reviewers:
+ arv@chromium.org

[arv (Not doing code reviews), 2015-06-02 22:27:08]

I wonder if we can get away with a data property on the prototype only. I know
it is not what WebIDL says (maybe we can get it changed) but we already report
the wrong thing.

[jsbell, 2015-06-03 17:06:23]

On 2015/06/02 22:25:26, arv wrote:
> > (new Image).__proto__ === document.createElement('img').__proto__
> > 
> > This actually returns false in Chrome - !?!?!?
> 
> https://code.google.com/p/chromium/issues/detail?id=310776

Awesome, thanks for the link.

On 2015/06/02 22:27:08, arv wrote:
> I wonder if we can get away with a data property on the prototype only. I know
> it is not what WebIDL says (maybe we can get it changed) but we already report
> the wrong thing.

sgtm; I haven't had cycles to poke at this, and probably won't for a bit.
(Anyone want to pick this up?)

[arv (Not doing code reviews), 2015-06-04 15:48:06]

I think we should just skip the Prototype part for now and follow ES6. It solves
the Window.prototype.toString bugs and it should have no memory or performance
implications.

[jsbell, 2015-06-05 19:00:44]

Bumped this to align (I think) with arv's proposal.

[arv (Not doing code reviews), 2015-06-05 19:05:48]

LGTM

Lets coordinate landing this ASAP after the next branch has been cut.

[jsbell, 2015-06-05 21:34:40]

Address the text failures from the try job, then putting this on ice for a
while.

Is "[object global]" a thing we need to preserve?

https://codereview.chromium.org/1017733003/diff/100001/LayoutTests/fast/worke...
File LayoutTests/fast/workers/shared-worker-replace-self-expected.txt (right):

https://codereview.chromium.org/1017733003/diff/100001/LayoutTests/fast/worke...
LayoutTests/fast/workers/shared-worker-replace-self-expected.txt:4: self:
[object SharedWorkerGlobalScope]
I assume this is correct? WebIDL doesn't say "global" anywhere.

https://codereview.chromium.org/1017733003/diff/100001/LayoutTests/fast/worke...
File LayoutTests/fast/workers/worker-replace-self-expected.txt (right):

https://codereview.chromium.org/1017733003/diff/100001/LayoutTests/fast/worke...
LayoutTests/fast/workers/worker-replace-self-expected.txt:4: self: [object
DedicatedWorkerGlobalScope]
Ditto.

https://codereview.chromium.org/1017733003/diff/100001/LayoutTests/http/tests...
File
LayoutTests/http/tests/w3c/webperf/approved/navigation-timing/html/idlharness-expected.txt
(right):

https://codereview.chromium.org/1017733003/diff/100001/LayoutTests/http/tests...
LayoutTests/http/tests/w3c/webperf/approved/navigation-timing/html/idlharness-expected.txt:4:
PASS Stringification of window
Yay!

[arv (Not doing code reviews), 2015-06-05 21:49:27]

On 2015/06/05 21:34:40, jsbell wrote:
> Address the text failures from the try job, then putting this on ice for a
> while.
> 
> Is "[object global]" a thing we need to preserve?

We should never return "[object global]".

[jsbell, 2015-09-23 17:42:28]

migrated to https://codereview.chromium.org/1366643003/