Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Boris Zbarsky]

On 6/10/16 11:25 AM, Florin Mezei wrote:

Are we still concerned about compatibility issues caused by this?


Somewhat, yes.  The fact the chrome just used to do [object Object] 
makes me a bit less concerned, and the fact that they're shipping the 
new setup also.  But there are still concerns, especially for Gecko-only 
codepaths (including addons).


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

RE: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Florin Mezei]

Are we still concerned about compatibility issues caused by this?

Regards,
Florin.

-Original Message-
From: dev-platform
[mailto:dev-platform-bounces+florin.mezei=softvisioninc...@lists.mozilla.org
] On Behalf Of Boris Zbarsky
Sent: Monday, June 06, 2016 11:30 PM
To: dev-platform@lists.mozilla.org
Subject: Re: Intent to implement and ship: Changing the toString result on
DOM prototype objects

On 6/3/16 11:41 AM, Boris Zbarsky wrote:
> * Chrome: has been shipping the behavior I'm proposing to change to 
> since Chrome 50, I believe.  Current Chrome release version is 51.

One note: earlier versions of Chrome claimed [object Object] for DOM
prototypes.  So the claim the Google folks are making is that returning
[object FooPrototype] is not needed for web compat.

> Possible alternatives: We could make @@toStringTag an accessor on the 
> prototype that returns different things for instances and the 
> prototype itself.

The hard part here is convincing the Chrome folks.

-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Boris Zbarsky]

On 6/3/16 11:41 AM, Boris Zbarsky wrote:

* Chrome: has been shipping the behavior I'm proposing to change to
since Chrome 50, I believe.  Current Chrome release version is 51.


One note: earlier versions of Chrome claimed [object Object] for DOM 
prototypes.  So the claim the Google folks are making is that returning 
[object FooPrototype] is not needed for web compat.



Possible alternatives: We could make @@toStringTag an accessor on the
prototype that returns different things for instances and the prototype
itself.


The hard part here is convincing the Chrome folks.

-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Nick Fitzgerald]

Ok, I've filed this bug to use @@toStringTag in the debugger instead of
Debugger.Object.prototype.class:
https://bugzilla.mozilla.org/show_bug.cgi?id=1278310

On Mon, Jun 6, 2016 at 10:35 AM, Boris Zbarsky  wrote:

> On 6/6/16 12:23 PM, Nick Fitzgerald wrote:
>
>> Yes (via the `Debugger.Object.prototype.class` getter) but unless I've
>> misunderstood the scope of this proposal, the class name exposed by that
>> getter should not change, only the `Object.prototype.toString.call(thing)`
>> would change.
>>
>
> You misunderstood the scope.  We would be changing the class string if we
> change the web-facing behavior here.
>
> Or put another way, if we want to change to @@toStringTag for DOM objects
> (which we do) and _if_ we want that change to change the behavior of
> Object.prototype.toString on DOM prototypes, then we would roll that out in
> two stages:
>
> 1)  Change the class strings on DOM prototype objects, so the
> Object.prototype.toString changes (and the Debugger.Object.prototype.class
> thing changes too, sadly).
>
> 2)  Add @@toStringTag stuff.
>
> The idea being to separate breakage from the Object.prototype.toString
> changing from breakage from using @@toStringTag instead of class strings to
> implement the behavior.
>
>
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Boris Zbarsky]

On 6/6/16 12:23 PM, Nick Fitzgerald wrote:

Yes (via the `Debugger.Object.prototype.class` getter) but unless I've
misunderstood the scope of this proposal, the class name exposed by that
getter should not change, only the `Object.prototype.toString.call(thing)`
would change.


You misunderstood the scope.  We would be changing the class string if 
we change the web-facing behavior here.


Or put another way, if we want to change to @@toStringTag for DOM 
objects (which we do) and _if_ we want that change to change the 
behavior of Object.prototype.toString on DOM prototypes, then we would 
roll that out in two stages:


1)  Change the class strings on DOM prototype objects, so the 
Object.prototype.toString changes (and the 
Debugger.Object.prototype.class thing changes too, sadly).


2)  Add @@toStringTag stuff.

The idea being to separate breakage from the Object.prototype.toString 
changing from breakage from using @@toStringTag instead of class strings 
to implement the behavior.


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Jim Blandy]

Well, the Debugger.Object.prototype.class getter shouldn't change, but
perhaps devtools shouldn't use it any more. Devtools should be displaying
objects in a way that doesn't surprise developers.

It seems to me the ideal behavior would be for Devtools to show objects in
the way that the ES6 standard toString methods would display them, and then
if those have been modified, attempt to display them as the modifications
suggest, to the extent that that can be done safely.

On Mon, Jun 6, 2016 at 9:23 AM, Nick Fitzgerald 
wrote:

> Yes (via the `Debugger.Object.prototype.class` getter) but unless I've
> misunderstood the scope of this proposal, the class name exposed by that
> getter should not change, only the `Object.prototype.toString.call(thing)`
> would change.
>
> On Mon, Jun 6, 2016 at 12:18 AM, Panos Astithas  wrote:
>
> > On Fri, Jun 3, 2016 at 8:21 PM, Nick Fitzgerald  >
> > wrote:
> >
> >> On Fri, Jun 3, 2016 at 8:41 AM, Boris Zbarsky  wrote:
> >>
> >> > Devtools bug: none so far, but maybe we need one?  Does devtools rely
> on
> >> > the JSClass name or Object.prototype.toString anywhere?
> >> >
> >>
> >> ​I think we are fine. There are certainly places where we use the
> >> `Object.prototype.toString.call(thing) === "[object Whatever]"`​ hack,
> but
> >> I don't see any instances that would be tripped up by these changes.
> >>
> >>
> >>
> https://dxr.mozilla.org/mozilla-central/search?q=path%3Adevtools+%22toString.call(%22=false
> >>
> >
> > Don't we still use the JSClass name in the variables view to indicate the
> > object type (reflected from Debugger.Object.prototype.class)?
> >
> > Panos
> >
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Nick Fitzgerald]

Yes (via the `Debugger.Object.prototype.class` getter) but unless I've
misunderstood the scope of this proposal, the class name exposed by that
getter should not change, only the `Object.prototype.toString.call(thing)`
would change.

On Mon, Jun 6, 2016 at 12:18 AM, Panos Astithas  wrote:

> On Fri, Jun 3, 2016 at 8:21 PM, Nick Fitzgerald 
> wrote:
>
>> On Fri, Jun 3, 2016 at 8:41 AM, Boris Zbarsky  wrote:
>>
>> > Devtools bug: none so far, but maybe we need one?  Does devtools rely on
>> > the JSClass name or Object.prototype.toString anywhere?
>> >
>>
>> ​I think we are fine. There are certainly places where we use the
>> `Object.prototype.toString.call(thing) === "[object Whatever]"`​ hack, but
>> I don't see any instances that would be tripped up by these changes.
>>
>>
>> https://dxr.mozilla.org/mozilla-central/search?q=path%3Adevtools+%22toString.call(%22=false
>>
>
> Don't we still use the JSClass name in the variables view to indicate the
> object type (reflected from Debugger.Object.prototype.class)?
>
> Panos
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[Panos Astithas]

On Fri, Jun 3, 2016 at 8:21 PM, Nick Fitzgerald 
wrote:

> On Fri, Jun 3, 2016 at 8:41 AM, Boris Zbarsky  wrote:
>
> > Devtools bug: none so far, but maybe we need one?  Does devtools rely on
> > the JSClass name or Object.prototype.toString anywhere?
> >
>
> ​I think we are fine. There are certainly places where we use the
> `Object.prototype.toString.call(thing) === "[object Whatever]"`​ hack, but
> I don't see any instances that would be tripped up by these changes.
>
>
> https://dxr.mozilla.org/mozilla-central/search?q=path%3Adevtools+%22toString.call(%22=false
>

Don't we still use the JSClass name in the variables view to indicate the
object type (reflected from Debugger.Object.prototype.class)?

Panos
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement and ship: Changing the toString result on DOM prototype objects

[smaug]

On 06/03/2016 06:41 PM, Boris Zbarsky wrote:

Summary: The current IDL spec says that Object.prototype.toString() on a DOM prototype 
object for interface Foo is "[object FooPrototype]", whereas
for instances of the interface it's "[object Foo]", and that's what we 
implement.  However, as we try to move to the ES6 @@toStringTag world, this
causes some problems, which are described in 
.  So there is a proposal 
to change the spec to
have the string be "[object Foo]" for the prototype as well.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1277880

Spec: Would get adjusted as needed.

Target release: 49

Preference: None

Devtools bug: none so far, but maybe we need one?  Does devtools rely on the 
JSClass name or Object.prototype.toString anywhere?

Behavior of other browsers:

* Chrome: has been shipping the behavior I'm proposing to change to since 
Chrome 50, I believe.  Current Chrome release version is 51.

* Safari (and WebKit nightly): has the behavior we currently have.

* Edge: has the behavior we currently have.

Possible alternatives: We could make @@toStringTag an accessor on the prototype 
that returns different things for instances and the prototype itself.

-Boris



Why is the change being done?  Why do we think @@toStringTag stuff is a good 
thing?
IMHO, the current Gecko behavior for toString makes more sense than the 
proposed one.
Foo object after all is quite different beast than its prototype so I'd expect 
toString() to reflect that.

Not really objecting anything here, but just wondering why this kind of change 
is being done.
W3C bug doesn't quite capture the reasoning here.


-Olli
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform