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

2016-06-14 Thread 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,

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

2016-06-10 Thread 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:

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

2016-06-06 Thread 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

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

2016-06-06 Thread 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

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

2016-06-06 Thread 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

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

2016-06-06 Thread 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

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

2016-06-06 Thread 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

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

2016-06-06 Thread 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? > >

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

2016-06-03 Thread 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