830376 - implement toJSON in mozIDOMApplication

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[Julien Wajsberg [:julienw]]

As a result we can't JSON.stringify them, and we can't call Object.keys on them, or iterate with a simple for loop.

This would be very useful for debugging our B2G work.

For exemple, you can try this line in a Web Console:

JSON.stringify(window.navigator.mozApps.getSelf())
=> {}

or

Object.keys(window.navigator.mozApps.getSelf())
=> []

Comment 1

[Boris Zbarsky [:bzbarsky]]

They're enumerable fine, just like any other object.  Are you running into the "the attributes are getters and setters on the prototype" issue, basically?  Try this:


  function foo() {
  }
  foo.prototype = { value: 2; }
  var x = new foo();
  Object.keys(x);

Do you expect to see "value" in there?

Comment 2

[Boris Zbarsky [:bzbarsky]]

And more to the point, do you see what you expect when you do:

 Object.keys(Object.getPrototypeOf(window.navigator.mozApps.getSelf()))

?

Comment 3

[Julien Wajsberg [:julienw]]

> Do you expect to see "value" in there?
I'm not sure. I'd say no.

> And more to the point, do you see what you expect when you do:

I'd say yes.

However, I took here the request because I thought it was showing the thing that we miss, but maybe not.

In B2G, we get some App object coming from the mozApps API (most notably the mozApps.getSelf().onsuccess handker). And this object is not stringified. I think the property of this object are not in the prototype.

I'll write a sample app later today to show what we'd like to have.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> I think the property of this object are not in the prototype.

It sure is.  onsuccess is a property on the prototype, with a getter and a setter and all that jazz.  That's how all WebIDL/DOM objects work: everything is always on the prototype.

Comment 5

[Julien Wajsberg [:julienw]]

yeah, I was not clear enough here.

Writing a sample app to be clearer ;)

Comment 6

[Julien Wajsberg [:julienw]]

Got it.


* with Firefox OS, go to http://everlong.org/mozilla/testcase-enumerable/
* install the app
* launch it from the homescreen
* see what's displayed under "log"

Expected:
* { downloadAvailable: false, etc }

Actual:
* {}

Comment 7

[Julien Wajsberg [:julienw]]

To be clear, I'd like to get the properties that have per-instance values, that is "removable", "origin", "downloading", etc.

Comment 8

[Bobby Holley (:bholley)]

(In reply to Julien Wajsberg [:julienw] from comment #7)
> To be clear, I'd like to get the properties that have per-instance values,
> that is "removable", "origin", "downloading", etc.

But those are all IDL-defined properties, which means that they're actually getters and setters that live on the prototype, right? Even if they're just stored as properties behind the scenes, there's not a sane way to serialize them, because on the client side they're just getters/setters that might do anything.

Comment 9

[Julien Wajsberg [:julienw]]

Ok I get it.

Would this still theorically be possible ? I mean, in some time ?

It doesn't disturb me much that we'd use the getters to get them. I mean, getters are here to abstract how we get the value so I'm ok with using the value it returns.

For setting (with JSON.parse for example) that's another story. But I'd be ok with only supporting this read-only as this is mainly for debugging.

And then we could have a special case for IDL-defined properties that would still be enumerable.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Note that individual interfaces can define custom JSON stringification behavior.  Maybe this one should.

> Would this still theorically be possible ? I mean, in some time ?

There are no plans to change the way IDL attributes are reflected (that being getter/setter pairs on the prototype).  Such plans would in any case need to be coordinated with other browsers, with the W3C, and with the ECMA-262 folks.

> And then we could have a special case for IDL-defined properties that would still be
> enumerable.

I'm not sure I follow.

Comment 11

[Julien Wajsberg [:julienw]]

(In reply to Boris Zbarsky (:bz) from comment #10)
> Note that individual interfaces can define custom JSON stringification
> behavior.  Maybe this one should.

Oh, I didn't know that. That would be good enough for my usage.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Please raise spec issues as needed!

Comment 13

[Julien Wajsberg [:julienw]]

I don't know where do to this. Morphing this bug would be sufficient ?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Spec issues go in the relevant standards group...  In this case, sounds like we're talking about DOMRequest, right?  Where is that being standardized?

If it's our own invention, I guess this bug is sufficient, but note that every wrinkle we add to it makes it harder to get others to standardize on it... while we come to depend on those wrinkles.

Comment 15

[Julien Wajsberg [:julienw]]

(In reply to Boris Zbarsky (:bz) from comment #14)
> Spec issues go in the relevant standards group...  In this case, sounds like
> we're talking about DOMRequest, right?  Where is that being standardized?

Nope, I am concerned about the mozIDOMApplication object defined in [1].

> If it's our own invention, I guess this bug is sufficient, but note that
> every wrinkle we add to it makes it harder to get others to standardize on
> it... while we come to depend on those wrinkles.

I agree but I'd say that adding a JSON serialization based on the IDL-defined properties whould not be so problematic.

[1] http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/apps/nsIDOMApplicationRegistry.idl

Comment 16

[Boris Zbarsky [:bzbarsky]]

OK.  In that case, we can just do it right now: define a method called toJSON on the interface and have it return an object with property/value pairs that expose whatever we want to expose.  The JSON.stringify algorithm checks for methods called toJSON and calls those before actually stringifying.

Comment 17

[Julien Wajsberg [:julienw]]

ok, thanks a lot Boris !

Alex, I think you had a similar problem on another object type, will you file another similar bug ?

Comment 18

[Alexandre Poirot [:ochameau]]

I wasn't able to enumerate thread list attributes in SMS app, but I really don't feel like opening a bug to request the enumerability on all WebAPI objects is a good idea, especially when I consider this as a nit more than a real issue.
It may also be another story as this sms thread list object is seems to be declared as a jsval:
http://mxr.mozilla.org/mozilla-central/source/dom/sms/interfaces/nsIDOMSmsManager.idl#33
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsIDOMDOMRequest.idl#17
nsIDOMSmsManager.getThreadList ---> nsIDOMMozSmsRequest > nsIDOMRequest.result ---> jsval

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Not blocking. But if it saves you time to fix this, then we would probably approve a safe patch.

Comment 20

[Firefox Bug Husbandry Bot]

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

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.