If setVersion() is not invoked on compileOptions, it ends up with
JSVERSION_UNKNOWN, which invokes findVersion() on the JSContext, which does a
bunch of crazy hunting of previous scripted stack frames that we most certainly
don't want for sandboxes, which are supposed to be controlled environments.
Using a separate JSContext in evalInSandbox isolates us from these effects, so
once we stop doing that we need to be more explicit here.
It would be nice to enforce this in New*FunctionForwarder, but we're already
in the target compartment at that point. :-(
We don't need to worry about this at the other callsites of
New*FunctionForwarder because:
* The stuff in XPCComponents is always invoked by System Principaled code.
* The stuff in StackScopedCloneRead only gets invoked when we're already done a
successful CheckedUnwrap inside the JS engine.
OS_LIBS for libraries that are not part of the gecko tree, EXTRA_LIBS for
libraries, such as NSPR, that are in the tree, but are not handled by
moz.build just yet. Those EXTRA_LIBS may also come from a system library.
However, in cases where the expanded variables are always empty for the
in-tree case, OS_LIBS is used (as for, e.g. MOZ_ZLIB_LIBS). OS_LDFLAGS is
used exclusively for non-library linker flags.
Always pass EXTRA_LIBS before OS_LIBS on linker command lines.
Forbid EXTRA_DSO_LDOPTS, SHARED_LIBRARY_LIBS and LIBS in Makefiles.
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.
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.
