========
https://hg.mozilla.org/integration/gaia-central/rev/d7c77807feb0
Author: Ryan VanderMeulen <rvandermeulen@mozilla.com>
Desc: Merge pull request #21461 from guilherme-pg/bug1035321-handle-accuracy
Bug 1035321 - Send the accuracy of locations to Find My Device's server.
========
https://hg.mozilla.org/integration/gaia-central/rev/e4dea2e018dc
Author: Guilherme Goncalves <guilherme.p.gonc@gmail.com>
Desc: Bug 1035321 - Send the accuracy of positions to Find My Device's server.
========
https://hg.mozilla.org/integration/gaia-central/rev/4a41159ba85b
Author: Etienne Segonzac <etienne@segonzac.info>
Desc: Merge pull request #21591 from etiennesegonzac/bug-1034347-bis
Bug 1034347 follow up - Fixing over paint issues r=21
========
https://hg.mozilla.org/integration/gaia-central/rev/370d06eab414
Author: Etienne Segonzac <etienne@segonzac.info>
Desc: Bug 1034347 follow up - Fixing over paint issues
While making sure
* we're not continuously creating/destroying layers during an edge gesture
* we don't reflow while quickly swiping through apps
========
https://hg.mozilla.org/integration/gaia-central/rev/005424e6e775
Author: Julien Wajsberg <felash@gmail.com>
Desc: Merge pull request #21613 from julienw/1033221-update-mozilla-download
Bug 1033221 - make mozilla-download and mozilla-get-url timeout in case ...
========
https://hg.mozilla.org/integration/gaia-central/rev/f9f04e06632c
Author: Julien Wajsberg <felash@gmail.com>
Desc: Bug 1033221 - make mozilla-download and mozilla-get-url timeout in case the FTP server doesn't answer r=me
Bump the version for mozilla-download
========
https://hg.mozilla.org/integration/gaia-central/rev/46a30986a7a6
Author: Douglas Sherk <github@sherk.me>
Desc: Merge pull request #21355 from gtorodelvalle/callscreen-bug-1018283-lockscreen-visual-refresh-revolutions
Bug 1018283 - [Follow-up 951665] Pending visual revision and adjustments callscreen-bug-1018283-lockscreen-visual-refresh-revolutions
========
https://hg.mozilla.org/integration/gaia-central/rev/f839ca378e60
Author: German Toro del Valle <gtorodelvalle@gmail.com>
Desc: Bug 1018283 - [Follow-up 951665] Pending visual revision and adjustments of the VR call screen when in lockscreen
========
https://hg.mozilla.org/integration/gaia-central/rev/e78d7cdd6e73
Author: pacorampas <b.frv@tid.es>
Desc: Merge pull request #20418 from pacorampas/ghost-count-button-dialer-1018494
Bug 1018494 - [B2G][Dialer] On the dialer app screen after the suggestions list is empty, tapping where the result count was, will still opens the overlay menu. r=etienne
========
https://hg.mozilla.org/integration/gaia-central/rev/124d8d641531
Author: Paco Rampas <pacorampas@gmail.com>
Desc: Bug 1018494 - [B2G][Dialer] On the dialer app screen after the suggestions list is empty, tapping where the result count was, will still opens the overlay menu.
Currently, BluetoothSocket leaks its file descriptor on close
operations. With this patch when Gecko closes an instance of
BluetoothSocket, the file descriptor is now closed as well.
It turns out the useAllocator argument is only used for the dipper types
(nsXPTType::{T_ASTRING, T_DOMSTRING, T_UTF8STRING, T_CSTRING}), while we
only pass true in cases where we don't have a dipper type:
* XPCConvert::JSArray2Native errors on those types;
* GetNamedPropertyAsVariantRaw() passes an interface type;
* nsXPCWrappedJSClass::CallMethod passes !param.IsDipper() for the first
calls and only reaches the last call for dependent types, which do not
include any of the dipper types;
* CallMethodHelper::ConvertIndependentParam handles dipper types earlier
* and CallMethodHelper::ConvertDependentParam handles dependent types.
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.
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.
