Closed Bug 1213056 Opened 9 years ago Closed 8 years ago

Change RTCStatsReport to be maplike.

Categories

(Core :: WebRTC, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla48
Tracking Status
firefox44 --- affected
firefox48 --- fixed

People

(Reporter: jib, Assigned: jib)

References

()

Details

(Keywords: dev-doc-needed, site-compat)

Attachments

(2 files)

Spec change.

Should keep old way for backwards compatibility as well for a release or two, with warnings.
backlog: --- → webrtc/webaudio+
Rank: 21
Priority: -- → P2
Assignee: nobody → jib
Rank: 21 → 19
Priority: P2 → P1
Version: 44 Branch → Trunk
Attachment #8728685 - Flags: review?(bzbarsky)
Attachment #8728686 - Flags: review?(docfaraday)
Comment on attachment 8728685 [details]
MozReview Request: Bug 1213056 - change getStats to be maplike.

https://reviewboard.mozilla.org/r/39017/#review35751

::: dom/media/PeerConnection.js:318
(Diff revision 1)
> +    Object.defineProperties(this.__DOM_IMPL__.wrappedJSObject, legacyProps);

This is exposing the chrome getter functions directly to content, isn't it?  Are you sure that's OK?  Please check with bholley.

::: dom/webidl/RTCStatsReport.webidl
(Diff revision 1)
> -  void forEach(RTCStatsReportCallback callbackFn, optional any thisArg);

The forEach/get/has methods in the chrome impl are dead code now, right?  If so, please remove them.

r=me modulo those issues, but please do check with bholley.
Attachment #8728685 - Flags: review?(bzbarsky)
https://reviewboard.mozilla.org/r/39017/#review35751

> This is exposing the chrome getter functions directly to content, isn't it?  Are you sure that's OK?  Please check with bholley.

FWIW the old code did something similar, expose a chrome value (with configurable:false, writable:false), but yes I changed it to a getter.

> The forEach/get/has methods in the chrome impl are dead code now, right?  If so, please remove them.

I thought I did, did I miss something?

Thanks, will do, but if you could hit the "Ship It" button in mozReview that would be great (required by auto-land I think).
Flags: needinfo?(bzbarsky)
Flags: needinfo?(bobbyholley)
> FWIW the old code did something similar, expose a chrome value (with configurable:false, writable:false)

No, it didn't.  The old code did:

292     Object.defineProperties(this.__DOM_IMPL__.wrappedJSObject, props);

where "props" is a (chrome-side, yes, but that doesn't matter in this case) object containing descriptors with "value: stat" where "stat" is the argument to forEach.  And forEach was implemented as:

297       cb.call(thisArg || this._report, this.get(key), key, this._report);

where this.get(key) returns like so:

307       let pubobj = Cu.createObjectIn(win);
308       Object.defineProperties(pubobj, props);
309       return pubobj;

so it was returning content-side objects and those were used as the values of the properties defined on the content-side reflector by makeStatsPublic.  Content never got to see chrome-side anything.

> I thought I did, did I miss something?

No, I did, because of the crappy diff viewer in mozreview.  :(

> but if you could hit the "Ship It" button in mozReview

Gah.  I thought I had.  How I hate mozreview....
Flags: needinfo?(bzbarsky)
Comment on attachment 8728685 [details]
MozReview Request: Bug 1213056 - change getStats to be maplike.

https://reviewboard.mozilla.org/r/39017/#review35783

Note that this still needs sign-off from bholley on the exposing chrome getters bit.  Of course I also couldn't redirect the original review request to him, because mozreview....
Attachment #8728685 - Flags: review+
Comment on attachment 8728685 [details]
MozReview Request: Bug 1213056 - change getStats to be maplike.

https://reviewboard.mozilla.org/r/39017/#review35789

::: dom/media/PeerConnection.js:309
(Diff revision 1)
> +        get: function() {

OK, I checked with bholley.  We do not, in fact, want to expose the chrome function directly.  Use Cu.cloneInto with cloneFunctions=true to clone things involving accessors into the content compartment.

This time I'm removing the r+ on purpose; I want to see the updated patch with cloneInto...
Attachment #8728685 - Flags: review+
(In reply to Boris Zbarsky [:bz] from comment #7)
> Comment on attachment 8728685 [details]
> MozReview Request: Bug 1213056 - change getStats to be maplike.
> 
> https://reviewboard.mozilla.org/r/39017/#review35789
> 
> ::: dom/media/PeerConnection.js:309
> (Diff revision 1)
> > +        get: function() {
> 
> OK, I checked with bholley.  We do not, in fact, want to expose the chrome
> function directly.  Use Cu.cloneInto with cloneFunctions=true to clone
> things involving accessors into the content compartment.

This isn't quite correct - cloneInto won't work with accessors AFAIK, because the structured clone algorithm invokes accessors while doing the clone. You'll need to use exportFunction for the accessors, but I also suggested using cloneInto(, { object literal}) to replace the createObjectIn and manual property definition.
Flags: needinfo?(bobbyholley)
Comment on attachment 8728686 [details]
MozReview Request: Bug 1213056 - update tests to use maplike getStats.

https://reviewboard.mozilla.org/r/39019/#review35881
Attachment #8728686 - Flags: review?(docfaraday) → review+
Comment on attachment 8728685 [details]
MozReview Request: Bug 1213056 - change getStats to be maplike.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/39017/diff/1-2/
Attachment #8728685 - Flags: review?(bzbarsky)
Comment on attachment 8728686 [details]
MozReview Request: Bug 1213056 - update tests to use maplike getStats.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/39019/diff/1-2/
Got distracted with other things. Sorry for the delay, and thanks again for the pointers.
Attachment #8728685 - Flags: review?(bzbarsky) → review+
Comment on attachment 8728685 [details]
MozReview Request: Bug 1213056 - change getStats to be maplike.

https://reviewboard.mozilla.org/r/39017/#review41805
https://hg.mozilla.org/mozilla-central/rev/1c12251da027
https://hg.mozilla.org/mozilla-central/rev/087f10d869e6
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Thanks! Note that there's a deprecation warning in console that triggers on legacy access (once per pc).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: