========
https://hg.mozilla.org/integration/gaia-central/rev/afa69c934fa1
Author: George <georgeiscoming@gmail.com>
Desc: Merge pull request #21456 from cctuan/1035010
Bug 1035010 - [edge gestures] Unlocalized App name appear while switching App (without changing locale after reboot)
========
https://hg.mozilla.org/integration/gaia-central/rev/f0f549a632a1
Author: cctuan <georgeiscoming@gmail.com>
Desc: Bug 1035010 - [edge gestures] Unlocalized App name appear while switching App (without changing locale after reboot)
========
https://hg.mozilla.org/integration/gaia-central/rev/ca48edf0ffa7
Author: Jared Hirsch <ohai@6a68.net>
Desc: Merge pull request #21506 from 6a68/bug-1034331-fxa-coppa-progress-bar
Bug 1034331 - Decrement fxa step count when going back from COPPA screen...
========
https://hg.mozilla.org/integration/gaia-central/rev/2e39a7c3a854
Author: Jared Hirsch <ohai@6a68.net>
Desc: Bug 1034331 - Decrement fxa step count when going back from COPPA screen to enter email screen. r=ferjm
Also: only increment the fxa step count if moving forward in the flow.
========
https://hg.mozilla.org/integration/gaia-central/rev/832854832480
Author: Julien Wajsberg <felash@gmail.com>
Desc: Merge pull request #21546 from julienw/1033472-improve-node-modules-dependencies
Bug 1033472 - Gaia linter, gaia-build tests aren't using NODE_MODULES_GI...
========
https://hg.mozilla.org/integration/gaia-central/rev/bf5f862ee2a5
Author: Julien Wajsberg <felash@gmail.com>
Desc: Bug 1033472 - Gaia linter, gaia-build tests aren't using NODE_MODULES_GIT_URL and so connect to Github ("make: *** [node_modules] Error 2") r=yurenju
This changes how the node_modules directory is generated. Indeed, we don't use
the temporary directory as a direct dependency now, because its name can change
and we don't need to run the new target if the name changes.
========
https://hg.mozilla.org/integration/gaia-central/rev/e1d948755673
Author: Marshall Culpepper <marshall.law@gmail.com>
Desc: Merge pull request #21470 from marshall/bug1035520_ftuPingSystemV2
Bug 1035520: Make FtuPing instantiable. r=alive
========
https://hg.mozilla.org/integration/gaia-central/rev/0ae4b0fea9d6
Author: Marshall Culpepper <marshall@mozilla.com>
Desc: Bug 1035520: Make FtuPing instantiable. r=alive
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.
========
https://hg.mozilla.org/integration/gaia-central/rev/056dbe15b2aa
Author: Julien Wajsberg <felash@gmail.com>
Desc: Bug 1033403 - [Messages] We don't stop rendering if we tap "back" too soon r=azasypkin
* moves the moment "initializeRendering" is called: in beforeEnter instead of
afterEnter.
* calls MessageManager.markThreadRead in afterEnterThread
* removes the 'done' handler in renderMessages because we don't need it now
