For locations, it always returns undefined. For windows, it returns undefined
unless there is a named subframe named "then", in which case that named
subframe is returned.
The idea is to be able to resolve promises with cross-origin objects.
MozReview-Commit-ID: HPyTvtwFdsG
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
This class doesn't have anything to do with __exposedProps__ any more,
so give it a more descriptive name. We'd still like to remove it
entirely eventually.
MozReview-Commit-ID: 87KCpG6f8rI
This patch gently removes support for __exposedProps__ by changing
ExposedPropertiesOnly::check() to always return false, while still
failing silently in deny for some kinds of access.
The tests that I changed all involve testing the behavior with
__exposedProps__. I adjusted them to expect it to fail, or to adjust
the error message they get when they fail. That seemed better than
deleting them entirely.
Note that test_bug1065185.html had a bug, so that it never executed
the first case. I fixed that, and then fixed up the test to work when
__exposedProps__ is not supported.
This also removes various bits of the test framework that use
__exposedProps__, but don't actually need to.
MozReview-Commit-ID: 8fvkAmITmXY
Most of the time, the return value of this method should be checked,
because behavior should depend on whether or not an exception is
thrown. However, if it is called immediately after a throw it doesn't
need to be checked because it will always return true. bz said there
is no public API that lets you assume there is an exception because it
would be "too easy to misuse".
MozReview-Commit-ID: CqyicBbcNjW
This file is included in caps/, but it only uses generic JS things,
aside from a macro.
AccessCheck.cpp was bootlegging xpcprivate.h.
MozReview-Commit-ID: C6fGOFxsTvg
The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
Boris and I debugged this. It looks like we're somehow ending up with an
XrayWaiver on the other end of a CrossOriginXrayWrapper. The specifics of how
this happens are a bit fuzzy to me, but it's presumably happening in all the
brain transplant weirdness we do when recomputing wrappers during document.domain.
Having an XrayWaiver there isn't unsafe - the wrapper computation algorithm
will ignore the waiver if the principals don't allow the caller to waive. But
it does throw a wrench in some brittle code that only expects certain kinds
of wrappers. Let's just do what XrayTraits::getTargetObject does. I don't think
this is really unsafe at all, because the only wrapper with a security boundary
is the CCW, and we're already stripping that off unconditionally with
Wrapper::wrappedObject.
value() can't assert hasValue() because too many places have plausible reasons for calling it on a PropertyDescriptor they basically know nothing about. One such place is CompartmentChecker::check(Handle<JSPropertyDescriptor>). Another is DefinePropertyByDescriptor. Maybe this will change with time.
In some cases we do things like `desc.hasWritable() && desc.writable() != existing_desc.writable()`. It is OK to write it this way, even though we have not checked existing_desc.hasWritable(), because in these cases we already know existingDesc is a complete property descriptor.
