This sets background_perceivable's nice at 10 and
background{,_homescreen}'s nice at 20. I'm a bit worried that this will
de-prioritize background_perceivable so much that music players may
start skipping. But we need to test.
--HG--
extra : rebase_source : e759ffb5bb58b89838c1dafdc49f737832593961
Previously, it was possible to return a dead preallocated process. This
patch eliminates or at least significantly reduces the likelihood of
this race.
--HG--
extra : rebase_source : f51022581edbdee8b72a8a56e296b6706bf1d165
InstallXBLField knows how to handle cross-compartment |callee|. However,
The current value will always be wrapped. We need to unwrap said wrappers,
otherwise we'll end up with objects that aren't functions.
Right now, DoInitJSClass only returns non-null if the class object is new
(and thus needs to have members installed on it). The code then goes and
unconditionally tries to install the members, null-checking and aborting
each time.
Instead, let's use an explicit boolean and one early return. This lets us
get a reference to our JSClass no matter what, which we need.
This confused me, because fields are, in fact, exposed via the prototype
via the complicated two-step solution defined in InstallField. As it turns
out, CompilePrototypeMembers throws if mClassObject ends up null.
We use XPCNativeWrapper.unwrap rather than .wrappedJSObject so that the tests
are agnostic to whether there's an Xray wrapper or not.
I converted test_tree_column_reorder.xul into a chrome test because it does
all sorts of crazy introspection on the binding, and it really should be
a chrome test anyway.
This generally works with membrane semantics, but breaks when same-compartment
security wrappers are involved. In particular, when Field{Getter,Setter} live
in the XBL scope and operate on NAC via nativeCall, the this object can't be
rewrapped, because otherwise a SOW will appear and break everything.
It's not ideal to hardcode the index of |this|, but there's not really a great
alternative. IIUC the layout isn't changing any time soon, and this code will
hopefully be short-lived anyway, since SCSWs are on their way out.
This patch has a bunch of semi-independent changes that unfortunately
couldn't be split apart without introducing hacks to make stuff build
on the intermediate patches. The main changes are:
- Moving TouchEventHandler from LayerView to JavaPanZoomController
- Registering the touch interceptor on the LayerView rather than the
TouchEventHandler
- Moving the Tab:HasTouchListener handler from GeckoApp to JPZC
The net effect of all of this is that the TouchEventHandler is hidden
behind the PanZoomController interface and not accessible to GeckoApp
or GeckoAppShell.
Additionally, some of the JPZC methods were renamed from onXXX to
handleXXX to maintain the convention that onXXX methods are "interface"
methods (i.e. exposed to arbitrary other code) whereas handleXXX
methods are private/package and should only be called in very specific
ways.
