Supports "class string" based on @@toStringTag.

Supports "class string" based on @@toStringTag.

Fixes the regression caused by a V8 change at http://crrev.com/1435273002 .
http://crrev.com/1435273002 changed a way to show the name of objects, and
Blink is now showing the wrong name for the interface prototype objects.

Before http://crrev.com/1435273002 :
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

Now:
console> HTMLBodyElement.prototype
=> HTMLElement {}

With this CL:
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

This CL mainly focuses to fix the regression.  Since the regression
happened back in M49 and the wrong name is very confusing for JS developers,
we might want to merge this fix into M49 branch.  However, this fix has the
following side effect, so we might not want to merge this fix into M49.

[Side effect]
Before:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object Object]

After:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object HTMLBodyElement]

(This side effect is correct in terms of the spec, but it breaks
the backward compatibility with the older versions of Chrome.)

Note that interface prototype objects, platform objects, etc. are expected
to have a class string, which should be implemented with @@toStringTag in
ES2015.  This is what V8 now expects Blink to use.
cf. http://heycam.github.io/webidl/#dfn-class-string

This CL adds @@toStringTag only to interface prototype objects, not to
other objects such as platform objects.  The reason is because we might or
might not want to merge this fix into M49, so we'd like to minimize the
change for now.

BUG=585028
TBR=haraken@chromium.org

Committed: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
Cr-Commit-Position: refs/heads/master@{#377890}

[Yuki, 2016-02-12 12:45:52]

Description was changed from

==========
Supports "class string" based on @@toStringTag.

Interface object, interface prototype object, etc. are expected to have
a class string, which should be implemented with @@toStringTag in ES6.
cf. http://heycam.github.io/webidl/#dfn-class-string

Since http://crrev.com/1435273002 changed a way to show the name of
objects, we need to update V8-binding in Blink accordingly.

BUG=585028
==========

to

==========
Supports "class string" based on @@toStringTag.

Interface prototype objects, platform objects, etc. are expected to have
a class string, which should be implemented with @@toStringTag in ES2015.
cf. http://heycam.github.io/webidl/#dfn-class-string

Since http://crrev.com/1435273002 changed a way to show the name of
objects, we need to update V8-binding in Blink accordingly.  Without
this CL, we see the following.
    console> HTMLBodyElement.prototype
    => HTMLElement {}
This is super confusing for JS developers.

BUG=585028
==========

[Yuki, 2016-02-12 12:46:28]

yukishiino@chromium.org changed reviewers:
+ haraken@chromium.org, verwaest@chromium.org

[Yuki, 2016-02-12 12:46:29]

haraken and Toon, could you guys review this CL?

[haraken, 2016-02-12 12:49:41]

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

[haraken, 2016-02-12 12:49:42]

+adamk

[Toon Verwaest, 2016-02-12 13:43:28]

lgtm

[caitp (gmail), 2016-02-12 14:44:46]

https://codereview.chromium.org/1685543002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/V8DOMConfiguration.cpp (right):

https://codereview.chromium.org/1685543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/V8DOMConfiguration.cpp:320: // See
also http://heycam.github.io/webidl/#es-platform-objects
Has there been more discussion about this since
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244 ?

[adamk, 2016-02-12 18:31:33]

https://codereview.chromium.org/1685543002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/V8DOMConfiguration.cpp (right):

https://codereview.chromium.org/1685543002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/V8DOMConfiguration.cpp:317: //
(|instanceTemplate|), too.  The reason that we don't set it is that
Can you say more about exactly what this patch does in the CL description? It
refers to the WebIDL spec, but since you're not setting the property on the
instances, we don't match the spec directly. See the bug caitp links to for more
discussion of the issues at hand; there's more at stake than just the
minor-dom-gc layout test.

[Yuki, 2016-02-15 06:49:10]

Description was changed from

==========
Supports "class string" based on @@toStringTag.

Interface prototype objects, platform objects, etc. are expected to have
a class string, which should be implemented with @@toStringTag in ES2015.
cf. http://heycam.github.io/webidl/#dfn-class-string

Since http://crrev.com/1435273002 changed a way to show the name of
objects, we need to update V8-binding in Blink accordingly.  Without
this CL, we see the following.
    console> HTMLBodyElement.prototype
    => HTMLElement {}
This is super confusing for JS developers.

BUG=585028
==========

to

==========
Supports "class string" based on @@toStringTag.

Fixes the regression caused by a V8 change at http://crrev.com/1435273002 .
http://crrev.com/1435273002 changed a way to show the name of objects, and
Blink is now showing the wrong name for the interface prototype objects.

Before http://crrev.com/1435273002 :
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

Now:
console> HTMLBodyElement.prototype
=> HTMLElement {}

With this CL:
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

This CL mainly focuses to fix the regression, and needs to be merged
to M49 since http://crrev.com/1435273002 was committed before M49 branch
and the wrong name is super confusing for JS developers.

Note that interface prototype objects, platform objects, etc. are expected
to have a class string, which should be implemented with @@toStringTag in
ES2015.  This is what V8 now expects Blink to use.
cf. http://heycam.github.io/webidl/#dfn-class-string

This CL adds @@toStringTag only to interface prototype objects, not to
other objects such as platform objects.  The reason is because we'd like
to merge this fix into M49, so we'd like to minimize the change.

BUG=585028
==========

[Yuki, 2016-02-15 06:54:53]

I updated the CL description.  Sorry for confusing you guys.

The main purpose of this CL is to fix the serious regression, NOT to (better)
conform to the spec.  We'd like to conform to the spec, but fixing the
regression is much more important and urgent.  This CL does NOT intend to be
perfect in terms of the spec.

Cheers,
Yuki Shiino

[Yuki, 2016-02-16 13:24:57]

On 2016/02/15 06:54:53, Yuki wrote:
> I updated the CL description.  Sorry for confusing you guys.
> 
> The main purpose of this CL is to fix the serious regression, NOT to (better)
> conform to the spec.  We'd like to conform to the spec, but fixing the
> regression is much more important and urgent.  This CL does NOT intend to be
> perfect in terms of the spec.
> 
> Cheers,
> Yuki Shiino

adamk@, could you take another look at this CL?

[adamk, 2016-02-16 18:30:50]

My worry is that this changes web-exposed behavior, not just what the console
shows. In particular, it changes the behavior of Object.prototype.toString when
called on DOM prototype objects. Before this change:

> Object.prototype.toString.call(HTMLBodyElement.prototype)
[object Object]

After:

> Object.prototype.toString.call(HTMLBodyElement.prototype)
[object HTMLBodyElement]

While making this change is likely something we want to do long-term (so this
change lgtm for trunk), I'm not convinced that it's something we'd want to
merge.

[Yuki, 2016-02-17 09:27:48]

Description was changed from

==========
Supports "class string" based on @@toStringTag.

Fixes the regression caused by a V8 change at http://crrev.com/1435273002 .
http://crrev.com/1435273002 changed a way to show the name of objects, and
Blink is now showing the wrong name for the interface prototype objects.

Before http://crrev.com/1435273002 :
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

Now:
console> HTMLBodyElement.prototype
=> HTMLElement {}

With this CL:
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

This CL mainly focuses to fix the regression, and needs to be merged
to M49 since http://crrev.com/1435273002 was committed before M49 branch
and the wrong name is super confusing for JS developers.

Note that interface prototype objects, platform objects, etc. are expected
to have a class string, which should be implemented with @@toStringTag in
ES2015.  This is what V8 now expects Blink to use.
cf. http://heycam.github.io/webidl/#dfn-class-string

This CL adds @@toStringTag only to interface prototype objects, not to
other objects such as platform objects.  The reason is because we'd like
to merge this fix into M49, so we'd like to minimize the change.

BUG=585028
==========

to

==========
Supports "class string" based on @@toStringTag.

Fixes the regression caused by a V8 change at http://crrev.com/1435273002 .
http://crrev.com/1435273002 changed a way to show the name of objects, and
Blink is now showing the wrong name for the interface prototype objects.

Before http://crrev.com/1435273002 :
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

Now:
console> HTMLBodyElement.prototype
=> HTMLElement {}

With this CL:
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

This CL mainly focuses to fix the regression.  Since the regression
happened back in M49 and the wrong name is very confusing for JS developers,
we might want to merge this fix into M49 branch.  However, this fix has the
following side effect, so we might not want to merge this fix into M49.

[Side effect]
Before:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object Object]

After:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object HTMLBodyElement]

(This side effect is correct in terms of the spec, but it breaks
the backward compatibility with the older versions of Chrome.)

Note that interface prototype objects, platform objects, etc. are expected
to have a class string, which should be implemented with @@toStringTag in
ES2015.  This is what V8 now expects Blink to use.
cf. http://heycam.github.io/webidl/#dfn-class-string

This CL adds @@toStringTag only to interface prototype objects, not to
other objects such as platform objects.  The reason is because we might or
might not want to merge this fix into M49, so we'd like to minimize the
change for now.

BUG=585028
==========

[Yuki, 2016-02-17 09:31:44]

On 2016/02/16 18:30:50, adamk wrote:
> My worry is that this changes web-exposed behavior, not just what the console
> shows. In particular, it changes the behavior of Object.prototype.toString
when
> called on DOM prototype objects. Before this change:
> 
> > Object.prototype.toString.call(HTMLBodyElement.prototype)
> [object Object]
> 
> After:
> 
> > Object.prototype.toString.call(HTMLBodyElement.prototype)
> [object HTMLBodyElement]
> 
> While making this change is likely something we want to do long-term (so this
> change lgtm for trunk), I'm not convinced that it's something we'd want to
> merge.

Thanks for raising the concern.  Now I understand it.

I updated the CL description so that it mentions about your concern and
(unintentional) side effect.

I changed my plan.  Once I get lgtm from you guys, I'm going to commit this CL
only to trunk.  We observe how much users complain the wrong name of objects,
and will make a decision whether we should merge this fix into M49 or not (or we
should do something else).

[adamk, 2016-02-17 18:53:26]

On 2016/02/17 09:31:44, Yuki wrote:
> On 2016/02/16 18:30:50, adamk wrote:
> > My worry is that this changes web-exposed behavior, not just what the
console
> > shows. In particular, it changes the behavior of Object.prototype.toString
> when
> > called on DOM prototype objects. Before this change:
> > 
> > > Object.prototype.toString.call(HTMLBodyElement.prototype)
> > [object Object]
> > 
> > After:
> > 
> > > Object.prototype.toString.call(HTMLBodyElement.prototype)
> > [object HTMLBodyElement]
> > 
> > While making this change is likely something we want to do long-term (so
this
> > change lgtm for trunk), I'm not convinced that it's something we'd want to
> > merge.
> 
> Thanks for raising the concern.  Now I understand it.
> 
> I updated the CL description so that it mentions about your concern and
> (unintentional) side effect.
> 
> I changed my plan.  Once I get lgtm from you guys, I'm going to commit this CL
> only to trunk.  We observe how much users complain the wrong name of objects,
> and will make a decision whether we should merge this fix into M49 or not (or
we
> should do something else).

Sounds good, thanks!

[Yuki, 2016-02-18 07:57:07]

The CQ bit was checked by yukishiino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-18 07:57:32]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1685543002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1685543002/180001

[commit-bot: I haz the power, 2016-02-18 09:12:19]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-18 09:12:19]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Yuki, 2016-02-18 11:09:49]

The CQ bit was checked by yukishiino@chromium.org

[Yuki, 2016-02-18 11:09:49]

The patchset sent to the CQ was uploaded after l-g-t-m from
verwaest@chromium.org, adamk@chromium.org
Link to the patchset: https://codereview.chromium.org/1685543002/#ps180001
(title: " ")

[commit-bot: I haz the power, 2016-02-18 11:10:25]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1685543002/180001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1685543002/180001

[commit-bot: I haz the power, 2016-02-18 11:44:55]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-18 11:44:57]

Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Yuki, 2016-02-24 14:34:47]

The CQ bit was checked by yukishiino@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-02-24 14:36:10]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1685543002/280001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1685543002/280001

[commit-bot: I haz the power, 2016-02-24 15:56:07]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-24 15:56:08]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Yuki, 2016-02-26 14:46:40]

Description was changed from

==========
Supports "class string" based on @@toStringTag.

Fixes the regression caused by a V8 change at http://crrev.com/1435273002 .
http://crrev.com/1435273002 changed a way to show the name of objects, and
Blink is now showing the wrong name for the interface prototype objects.

Before http://crrev.com/1435273002 :
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

Now:
console> HTMLBodyElement.prototype
=> HTMLElement {}

With this CL:
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

This CL mainly focuses to fix the regression.  Since the regression
happened back in M49 and the wrong name is very confusing for JS developers,
we might want to merge this fix into M49 branch.  However, this fix has the
following side effect, so we might not want to merge this fix into M49.

[Side effect]
Before:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object Object]

After:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object HTMLBodyElement]

(This side effect is correct in terms of the spec, but it breaks
the backward compatibility with the older versions of Chrome.)

Note that interface prototype objects, platform objects, etc. are expected
to have a class string, which should be implemented with @@toStringTag in
ES2015.  This is what V8 now expects Blink to use.
cf. http://heycam.github.io/webidl/#dfn-class-string

This CL adds @@toStringTag only to interface prototype objects, not to
other objects such as platform objects.  The reason is because we might or
might not want to merge this fix into M49, so we'd like to minimize the
change for now.

BUG=585028
==========

to

==========
Supports "class string" based on @@toStringTag.

Fixes the regression caused by a V8 change at http://crrev.com/1435273002 .
http://crrev.com/1435273002 changed a way to show the name of objects, and
Blink is now showing the wrong name for the interface prototype objects.

Before http://crrev.com/1435273002 :
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

Now:
console> HTMLBodyElement.prototype
=> HTMLElement {}

With this CL:
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

This CL mainly focuses to fix the regression.  Since the regression
happened back in M49 and the wrong name is very confusing for JS developers,
we might want to merge this fix into M49 branch.  However, this fix has the
following side effect, so we might not want to merge this fix into M49.

[Side effect]
Before:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object Object]

After:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object HTMLBodyElement]

(This side effect is correct in terms of the spec, but it breaks
the backward compatibility with the older versions of Chrome.)

Note that interface prototype objects, platform objects, etc. are expected
to have a class string, which should be implemented with @@toStringTag in
ES2015.  This is what V8 now expects Blink to use.
cf. http://heycam.github.io/webidl/#dfn-class-string

This CL adds @@toStringTag only to interface prototype objects, not to
other objects such as platform objects.  The reason is because we might or
might not want to merge this fix into M49, so we'd like to minimize the
change for now.

BUG=585028
TBR=haraken@chromium.org
==========

[Yuki, 2016-02-26 14:47:10]

The CQ bit was checked by yukishiino@chromium.org

[Yuki, 2016-02-26 14:47:11]

The patchset sent to the CQ was uploaded after l-g-t-m from
verwaest@chromium.org, adamk@chromium.org
Link to the patchset: https://codereview.chromium.org/1685543002/#ps400001
(title: "Updated test expectations.")

[commit-bot: I haz the power, 2016-02-26 14:47:36]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1685543002/400001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1685543002/400001

[commit-bot: I haz the power, 2016-02-26 15:13:50]

Description was changed from

==========
Supports "class string" based on @@toStringTag.

Fixes the regression caused by a V8 change at http://crrev.com/1435273002 .
http://crrev.com/1435273002 changed a way to show the name of objects, and
Blink is now showing the wrong name for the interface prototype objects.

Before http://crrev.com/1435273002 :
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

Now:
console> HTMLBodyElement.prototype
=> HTMLElement {}

With this CL:
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

This CL mainly focuses to fix the regression.  Since the regression
happened back in M49 and the wrong name is very confusing for JS developers,
we might want to merge this fix into M49 branch.  However, this fix has the
following side effect, so we might not want to merge this fix into M49.

[Side effect]
Before:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object Object]

After:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object HTMLBodyElement]

(This side effect is correct in terms of the spec, but it breaks
the backward compatibility with the older versions of Chrome.)

Note that interface prototype objects, platform objects, etc. are expected
to have a class string, which should be implemented with @@toStringTag in
ES2015.  This is what V8 now expects Blink to use.
cf. http://heycam.github.io/webidl/#dfn-class-string

This CL adds @@toStringTag only to interface prototype objects, not to
other objects such as platform objects.  The reason is because we might or
might not want to merge this fix into M49, so we'd like to minimize the
change for now.

BUG=585028
TBR=haraken@chromium.org
==========

to

==========
Supports "class string" based on @@toStringTag.

Fixes the regression caused by a V8 change at http://crrev.com/1435273002 .
http://crrev.com/1435273002 changed a way to show the name of objects, and
Blink is now showing the wrong name for the interface prototype objects.

Before http://crrev.com/1435273002 :
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

Now:
console> HTMLBodyElement.prototype
=> HTMLElement {}

With this CL:
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

This CL mainly focuses to fix the regression.  Since the regression
happened back in M49 and the wrong name is very confusing for JS developers,
we might want to merge this fix into M49 branch.  However, this fix has the
following side effect, so we might not want to merge this fix into M49.

[Side effect]
Before:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object Object]

After:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object HTMLBodyElement]

(This side effect is correct in terms of the spec, but it breaks
the backward compatibility with the older versions of Chrome.)

Note that interface prototype objects, platform objects, etc. are expected
to have a class string, which should be implemented with @@toStringTag in
ES2015.  This is what V8 now expects Blink to use.
cf. http://heycam.github.io/webidl/#dfn-class-string

This CL adds @@toStringTag only to interface prototype objects, not to
other objects such as platform objects.  The reason is because we might or
might not want to merge this fix into M49, so we'd like to minimize the
change for now.

BUG=585028
TBR=haraken@chromium.org
==========

[commit-bot: I haz the power, 2016-02-26 15:13:52]

Committed patchset #21 (id:400001)

[commit-bot: I haz the power, 2016-02-26 15:15:22]

Description was changed from

==========
Supports "class string" based on @@toStringTag.

Fixes the regression caused by a V8 change at http://crrev.com/1435273002 .
http://crrev.com/1435273002 changed a way to show the name of objects, and
Blink is now showing the wrong name for the interface prototype objects.

Before http://crrev.com/1435273002 :
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

Now:
console> HTMLBodyElement.prototype
=> HTMLElement {}

With this CL:
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

This CL mainly focuses to fix the regression.  Since the regression
happened back in M49 and the wrong name is very confusing for JS developers,
we might want to merge this fix into M49 branch.  However, this fix has the
following side effect, so we might not want to merge this fix into M49.

[Side effect]
Before:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object Object]

After:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object HTMLBodyElement]

(This side effect is correct in terms of the spec, but it breaks
the backward compatibility with the older versions of Chrome.)

Note that interface prototype objects, platform objects, etc. are expected
to have a class string, which should be implemented with @@toStringTag in
ES2015.  This is what V8 now expects Blink to use.
cf. http://heycam.github.io/webidl/#dfn-class-string

This CL adds @@toStringTag only to interface prototype objects, not to
other objects such as platform objects.  The reason is because we might or
might not want to merge this fix into M49, so we'd like to minimize the
change for now.

BUG=585028
TBR=haraken@chromium.org
==========

to

==========
Supports "class string" based on @@toStringTag.

Fixes the regression caused by a V8 change at http://crrev.com/1435273002 .
http://crrev.com/1435273002 changed a way to show the name of objects, and
Blink is now showing the wrong name for the interface prototype objects.

Before http://crrev.com/1435273002 :
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

Now:
console> HTMLBodyElement.prototype
=> HTMLElement {}

With this CL:
console> HTMLBodyElement.prototype
=> HTMLBodyElement {}

This CL mainly focuses to fix the regression.  Since the regression
happened back in M49 and the wrong name is very confusing for JS developers,
we might want to merge this fix into M49 branch.  However, this fix has the
following side effect, so we might not want to merge this fix into M49.

[Side effect]
Before:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object Object]

After:
console> Object.prototype.toString.call(HTMLBodyElement.prototype)
=> [object HTMLBodyElement]

(This side effect is correct in terms of the spec, but it breaks
the backward compatibility with the older versions of Chrome.)

Note that interface prototype objects, platform objects, etc. are expected
to have a class string, which should be implemented with @@toStringTag in
ES2015.  This is what V8 now expects Blink to use.
cf. http://heycam.github.io/webidl/#dfn-class-string

This CL adds @@toStringTag only to interface prototype objects, not to
other objects such as platform objects.  The reason is because we might or
might not want to merge this fix into M49, so we'd like to minimize the
change for now.

BUG=585028
TBR=haraken@chromium.org

Committed: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
Cr-Commit-Position: refs/heads/master@{#377890}
==========

[commit-bot: I haz the power, 2016-02-26 15:15:23]

Patchset 21 (id:??) landed as
https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
Cr-Commit-Position: refs/heads/master@{#377890}

[Yuki, 2016-02-26 15:17:55]

haraken@, allow me TBR because I'd really like to fix this issue at least in
M50.

[haraken, 2016-02-26 17:09:02]

On 2016/02/26 15:17:55, Yuki wrote:
> haraken@, allow me TBR because I'd really like to fix this issue at least in
> M50.

Sorry, I wasn't thinking I'm blocking this CL. LGTM.

[jsbell, 2016-02-26 17:40:32]

On 2016/02/12 14:44:46, caitp (OOO til 1-3-2016) wrote:
> Has there been more discussion about this since
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244 ?

I dropped a note on that thread. We should report on the success of this
(sticks/reverted) back to that bug, to inform WebIDL spec changes.

[Yuki, 2016-03-01 05:39:49]

On 2016/02/26 17:40:32, jsbell wrote:
> On 2016/02/12 14:44:46, caitp (OOO til 1-3-2016) wrote:
> > Has there been more discussion about this since
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244 ?
> 
> I dropped a note on that thread. We should report on the success of this
> (sticks/reverted) back to that bug, to inform WebIDL spec changes.

Thanks for the note.  I'll report our progress there.