merge b2g-inbound to mozilla-central a=merge
merge mozilla-inbound to mozilla-central a=merge
merge fx-team to mozilla-central a=merge
Bug 1036518 - Back out cset cc20208a6eb4 (bug 1034247) for causing blurry painting and janky scrolling on B2G/Fennec on some devices. r=me a=backout
Bug 1031226 - [vibration] navigator.vibrate([]) fails to cancel a pre-existing instance of the processing vibration patterns algorithm, r=mounir

--HG--
extra : rebase_source : a4a5d894ce010ebf6ac9d97b03b05986e0a42dd6
Bug 982039 - Radio input required not working when element disabled by js, r=bz

--HG--
extra : rebase_source : 53b134dc349ec7068c4543469e89f7e40073ea15
Merge mozilla-central and inbound
Bug 1034627 part 1 - Add some new string APIs. r=terrence
Bug 1034627 part 2 - Fix xpconnect Dump and Print functions to work with Latin1 strings and nursery strings. r=bholley
Bug 1034627 part 3 - Fix SandboxDump, AccessCheck.cpp to work with Latin1 strings and nursery strings. r=bholley
Bug 1035773 - Change AsyncShutdown timeout crash prefix from "ERROR:" to "FATAL ERROR:"; r=Yoric
Bug 1032814 - Gecko media plugins should not automatically enable plugin from system locations. Instead, there is a programmatic API for registering available plugins which will be used by addons or the addon manager. For development, there is also an environment variable. r=josh/jesup

--HG--
extra : rebase_source : dcd8708ac50a96cff3c59d3c4a531288c19bd961
Bug 1034239 - Add Proxies to ForceCOWBehavior. r=gabor
Bug 1034239 - Replace GentlyOpaque with an "Xray-to-nothing" wrapper. r=gabor

I did this wrong before. Making this a SecurityWrapper means that the caller does
not subsumes the target, and that the target therefore needs to be protected
from the caller. But GentlyOpaque was supposed to be an analog of PermissiveXray
for use when no useful XrayTraits exist, so it should behave similarly.

If we make this a Filtering Security Wrapper, we get a bunch of assertions where we
expect CheckedUnwrap to succeed for a chrome-side wrapper. And we can't making it
a Filtering Non-Security Wrapper, because then the filtering policy isn't even
consulted (an optimization in jsproxy.cpp).

Really, we want all of the Xray machinery (like the ability to waive and to place
expandos), and we just don't want to resolve any properties. This patch does this.
Bug 1036695 - enable mozApps debug logging when running tests; r=fabrice
Backed out changeset 91f25a63dea9 (bug 1032814) for build failures
Bug 1034262 - Don't use wantXrays for requiresAddonGlobal sandboxes. r=gabor
Bug 1034262 - Honor the wantXrays of both sides of the membrane when computing same-origin wrappers. r=gabor

The basic problem in the testcase is that one compartment requests same-origin
Xrays via wantXrays=true (the default for Sandboxes) while the other does not.
The current code only considers the wantXrays flag of the compartment performing
the access, so we end up in a situation where we have same-origin compartments,
but Xray in one direction and Transparent in the other.

This is a problem for crossCompartmentFunction.apply(null, [arg]). If both
globals get transparent wrappers, there's obviously no problem. And if both
globals get XrayWrappers, then the |apply| happens on the XrayWrapper of the
function in the caller's compartment. So the Array is unpacked in the caller's
compartment, and again we have no problem.

But if the caller gets Transparent and the callee gets Xrays, then we end up
invoking |apply| from the callee's side, which then gets an XrayWrapper to the
array. This XrayWrapper may do surprising things, leading to the odd situation
in the testcase.

Same-origin Xrays are kind of broken anyway, but I don't think we'll ever be
able to get rid of them. So the most sensible thing to do is probably to honor
the flag (if set) from either compartment. This patch does that.
Bug 1037000: Include "default communications device" in the audio input enumeration for gUM r=padenot
Bug 1036648 - Reject promise on uninstall failure on Mac. r=myk