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.
This is required in order to avoid exposing resolve hook effects when
Object.freeze() is invoked on the global. The freeze() call first enumerates
the object, after which point any lazy properties need to be resolve so that
we can safely mark the object as non-extensible.
Earlier in the function, there is an always-returning branch if |flat| is
non-null, so this code is only reached with a null |flat|, and the removed
code is dead.
The -*- file variable lines -*- establish per-file settings that Emacs will
pick up. This patch makes the following changes to those lines (and touches
nothing else):
- Never set the buffer's mode.
Years ago, Emacs did not have a good JavaScript mode, so it made sense
to use Java or C++ mode in .js files. However, Emacs has had js-mode for
years now; it's perfectly serviceable, and is available and enabled by
default in all major Emacs packagings.
Selecting a mode in the -*- file variable line -*- is almost always the
wrong thing to do anyway. It overrides Emacs's default choice, which is
(now) reasonable; and even worse, it overrides settings the user might
have made in their '.emacs' file for that file extension. It's only
useful when there's something specific about that particular file that
makes a particular mode appropriate.
- Correctly propagate settings that establish the correct indentation
level for this file: c-basic-offset and js2-basic-offset should be
js-indent-level. Whatever value they're given should be preserved;
different parts of our tree use different indentation styles.
- We don't use tabs in Mozilla JS code. Always set indent-tabs-mode: nil.
Remove tab-width: settings, at least in files that don't contain tab
characters.
- Remove js2-mode settings that belong in the user's .emacs file, like
js2-skip-preprocessor-directives.
This is unnecessary now that object jsids no longer exist. Both string and
symbol jsids point only to GC things in the atoms compartment, which are safe
to pass to any compartment without wrapping.
--HG--
extra : rebase_source : 82c21e8474df05b1bb42c14d872c981205bbe879
Layout: js/src/vm/Symbol.h defines the new class JS::Symbol. JS::Symbol is the
same size as JSString on all platforms, because the allocator does not support
smaller allocations.
Allocation: Since the purpose of symbols is to serve as property keys, they are
always allocated in the atoms compartment.
We take a lock when allocating. This could probably be replaced with a
main-thread-only assertion. However, if atom allocation is not already a
bottleneck, symbol allocation probably never will be.
Symbols are given their own finalize-class in the GC. This means we allocate a
page per zone for symbols, even though they are only ever allocated in the
atoms zone. Terrence thought this could be easily fixed later. It should be; we
never touch the page, but a 32-bit virtual address space does not just have
infinite pages to spare.
A jsapi-test exercises the new symbol allocation code. A few oddities in
jsapi-tests are fixed in passing.
Discussion after review led to some new assertions about minimum object size in
AllocateObject and AllocateNonObject.
--HG--
extra : rebase_source : 45abb651d3b1b493d77a5dd0eb554f96b058c63a
