Bug 746714 - add a memory reporter for telemetry; r=taras,njn
Bug 792164 - add mozdevice to virtualenv in m-c;r=gps
Bug 798419 - Fix incorrect spellings of success(ful) in test output; r=me
Bug 798346 - nsContentUtils::PreserveWrapper should explicitly QI its argument to the CC ISupports. r=peterv
Bug 761695 - Fix inaccurate commenting. r=peterv

The .wrappedJSObject property only exists when the Xray wrapper subsumes the wrappee.
Bug 761695 - Simplify XPCWN Xray holder creation. r=peterv

The major semantic change here is that we parent holders directly to their
global. This should be fine.
Bug 761695 - Stop stashing a raw WN pointer in XPCWN Xray holders. r=peterv

We might as well do this dynamically, which simplifies the code. Note that we
could avoid the reserved slot by parenting the holder to the wrapper. But the
JS parent API is deprecated, and we need to move away from it to reserved slots
anyhow. We might as well start here, with the added advantage that parenting
to the global makes us consistent with the other Xray types.
Bug 761695 - Make Xray traits inherit from a common superclass and give them a singleton instance. r=peterv

There's some code that can be shared between different Xray traits, but can't
(yet) be hoisted into XrayWrapper, because it needs to be callable from outside
XrayWrapper where we don't have the appropriate template parameters. Moreover,
this code benefits from virtual function specialization. The use case here is
illuminated in the next patch.

For the moment, we skip converting the bulk of the traits calls to virtual
methods, because they're working just fine.
Bug 761695 - Hoist getInnerObject into XrayTraits. r=peterv

The only special handling here with wrapped natives is to make sure that we
bypass outer windows. But we can do this with js::UnwrapObject.
Bug 761695 - Rename getInnerObject to getTargetObject. r=peterv

The current name potentially implies that the object returned is an inner
object in the JS sense, which isn't true. Really we just want the thing
we're Xraying to.
Bug 761695 - Hoist call and construct traps into Traits, since the current implementations are XPCWN-specific. r=peterv
Bug 761695 - Get the WN directly from the wrapper. r=peterv

All this indirection was getting seriously mucky. This, incidentally, means that
the XPCWN holder no longer needs a reserved slot pointing to the WN.
Bug 761695 - Unify holder creation and access. r=peterv

With this patch, all holders are created lazily. There are two common accessors,
getHolder() and ensureHolder(). The former returns null if no holder exists, the
latter lazily creates the holder if it doesn't exist. It does this by calling into
a virtual trap on XrayTraits, which lets the appropriate Xray type do its thing.
Bug 761695 - Move Xray expando infrastructure further down in the file. r=peterv

Just cut/paste. No code changes.
Bug 761695 - Hoist Xray identification machinery into XrayWrapper, and use it for trait identification. r=peterv

We don't currently have a good way of selecting the traits used by a given Xray
wrapper. This lets us do that.

Note: We add a call to js::UnwrapObject to GetXrayType while hoisting it. When
it was used only in WrapperFactory, this was unnecessary, because |obj| was
always unwrapped. But for our new purposes, it might not be. Aside from that,
there are no changes to the function.
Bug 761695 - Hoist expando infrastructure into XrayTraits. r=peterv

It's still WN-only, now we can move the WN-only bits into virtual traps.

Note that the new-binding reparenting code will need to have a call to
CloneExpandoChain.
Bug 761695 - Make expando chain getting/setting a virtual trap. r=peterv
Bug 761695 - Move wrapper preservation stuff into a virtual trap. r=peterv

I'm not sure this stuff is correct for non-WN objects. Hopefully that will
come out in review.

Anyway, with this change, the expando infrastructure in XrayTraits is now
fully generic and non-WN-specific. To make things work for other objects,
we now need to implement the virtual traps and hoist the code that calls the
expando machinery out of XPCWrappedNativeXrayTraits.
Bug 761695 - Implement expando traps for ProxyXrayTraits DOMXrayTraits. r=peterv

For new DOM proxies, we could probably use the Xray expando machinery for the
regular expando object as well, and free up one of the reserved slots. That's
more than I want to bite off for the moment, though.

I also decided not to block on bug 760095 and just kick the problem of globals
with new binding down the road a little bit.
Bug 761695 - Reorder checks for expandos and nodePrincipal. r=peterv

Peter and I decided this was ok. We can't hoist expando stuff otherwise.