Without this change, we could do a "short" get of a string (e.g. from
XMLHttpRequest), then do another get that returns the same stringbuffer but a
longer length. But we wouldn't notice, hit our cache, and return the same,
too-short, external string. The site would not see the new data it should have
seen.
The problem is that JSJitGetterInfo doesn't contain a callee. So we can't use
xpc::XrayAwareCalleeGlobal in a specialized getter, because we don't have our
callee function available.
Intl API (ECMA-402) already supports most web browsers such as Edge (including Windows 10 Mobile), Chrome (including Android), and upcoming Safari 10(https://developer.apple.com/library/prerelease/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_10_0.html).
Also IDN2008 support, and number control by <input type="number"> require ICU. And, although gfx has own unicode table, we want to remove this if ICU is supported on all platform.
Also, new L20N framework (aka L20N) wants to use Intl API to localize UI.
So I would like to use ICU as default on Fennec Android.
Negative issue is file size. ICU has big table, file size of libxul.so will be following. This support requires additional 4.4MB.
before this ... 26287379 bytes
after this ... 30692696 bytes
Although android OS already has ICU, ICU version is different per OS version. And our ICU requirement is 50.1+ (Android 4.0 uses ICU 48) and exported fucntion name of ICU has ICU version suffix. So we cannot use it.
MozReview-Commit-ID: 5R5iNMzWNjS
--HG--
extra : rebase_source : fceb3ee320f885e7c03749f76cf0ad7699a21c2c
nsIXPCScriptable flags handling in xpc_map_end.h is a bit of a mess.
- Half the flags relate to whether various functions are defined (PreCreate,
GetProperty, etc). These are set using the XPC_MAP_WANT_* macros;
for each one xpc_map_end.h inserts the corresponding flag using the
preprocessor (see XPC_MAP_CLASSNAME::GetScriptableFlags()).
- The other half of the flags relate to other things (IS_GLOBAL_OBJECT,
DONT_REFLECT_INTERFACE_NAMES, etc). These are set using the XPC_MAP_FLAGS
macro.
Having two similar but different mechanisms to set the flags for a class is
confusing. (Indeed, until recently we had some classes where a single flag was
redundantly specified via both mechanisms.) Note also that the classes done in
dom/base/nsIDOMClassInfo.h also specify all the flags in a single value,
similar to how XPC_MAP_FLAGS works.
This patch removes the XPC_MAP_WANT_* macros. All flags are now set
via XPC_MAP_FLAGS. This is a significant simplification to xpc_map_end.h and
all the places that use it.
The downside of this change is that I had to change the flag constants from
class constants (i.e. nsIXPCScriptable::FOO) to macros (i.e.
NSIXPCSCRIPTABLE_FOO) because they need to be used in #if statements like this
in xpc_map_end.h:
#if !((XPC_MAP_FLAGS) & NSIXPCSCRIPTABLE_WANT_PRECREATE)
and you can't use a '::'-qualified name inside a #if. I think this downside is
outweighed by the simplification described above.
Overall the patch removes 80 lines of code.
--HG--
extra : rebase_source : 6d5c341d0deba8f1529d81c17bb8819e09620b05
XPCNativeScriptableCreateInfo is now a very thin wrapper around
nsIXPCScriptable. Removing it simplifies things quite a bit.
Note especially the change to GatherScriptableCreateInfo(), which is a
confusing function. Previously its fourth argument was never touched it was
called, but it did have a return value. Now the fourth argument is touched and
effectively replaces that return value, and the function now returns void.
* * *
Bug 1330904 - fixups. r=mccr8.
I will fold this into the previous patch before landing.
--HG--
extra : rebase_source : 22e7fd0c44dd7c4174f8edf3e1d3ae362bf95757
This just wraps all the XRE method calls to go through the Bootstrap API
instead of relying on the XPCOM glue methods.
--HG--
extra : rebase_source : eccbe18b9b21ca1ab6c403515ffd60f0a9174d9c
XPCNativeScriptableInfo is now a very thin wrapper around nsIXPCScriptable, and
it uses manual memory management. Removing it simplifies things quite a bit.
In particular, when setting XPCWrappedNative::mScriptable in
XPCWrappedNative::WrapNewGlobal() and XPCWrappedNative::Init() we no longer
have to worry about sharing the XPCNativeScriptableInfo object with the proto.
And XPCWrappedNative::{Init,Destroy}() have similar simplifications.
--HG--
extra : rebase_source : e58eb28f1574224a8e8badf25fcfa25e5a5b8ad8
This patch adjusts the values so there are no skipped bits, and removes the
no-longer-used RESERVED flag.
--HG--
extra : rebase_source : 88a50110d66ad85c1277213afea7e08f7aa9538a
WantFoo() and the similar methods remain, but they've been moved from
XPCNativeScriptableFlags to nsIXPCScriptable.
One consequence of this change is that in places where we used to get the flags
from an XPCNativeScriptableCreateInfo we now need a null check on the
nsIXPCScriptable. (This isn't true when getting flags from
XPCNativeScriptableInfo, however, because nsIXPCScriptable is always non-null
within that type.)
--HG--
extra : rebase_source : 3d1e1d1c313b4629bb2e337cc2fb7c0d1092ed99
I'd like to remove XPC_MAP_WANT_* altogether and use XPC_MAP_FLAGS for all the
nsIXPCScriptable flag setting, but I haven't worked out how to handle the
method definitions in xpc_map_end.h yet. In the meantime, it seems good to make
the flag setting more consistent and explicit.
In particular, the three "Module" classes have "#define XPC_MAP_WANT_CALL" and
"#define XPC_MAP_FLAGS nsIXPCScriptable::WANT_CALL" which both have the same
effect. The patch removes the latter, to make them consistent with other
classes.
--HG--
extra : rebase_source : 3119e895809bb14e63f61e4e440c84e16cc4c5f9
As far as I can tell, this covers all the remaining threads which we start
using PR_CreateThread, except the ones that are created inside NSPR or NSS,
and except for the Shutdown Watchdog thread in nsTerminator.cpp and the
CacheIO thread. The Shutdown Watchdog thread stays alive past leak detection
during shutdown (by design), so we'd report leaks if we profiled it. The
CacheIO thread seems to stay alive past shutdown leak detection sometimes as
well.
This adds a AutoProfilerRegister stack class for easy registering and
unregistering. There are a few places where we still call
profiler_register_thread() and profiler_unregister_thread() manually, either
because registration happens conditionally, or because there is a variable that
gets put on the stack before the AutoProfilerRegister (e.g. a dynamically
generated thread name). AutoProfilerRegister needs to be the first object on
the stack because it uses its own `this` pointer as the stack top address.
MozReview-Commit-ID: 3vwhS55Yzt
--HG--
extra : rebase_source : 56dd27282e7bd09a7e7dc7ca09ccfe3a0198e7af
The only non-trivial implementation of this method is in nsEventTargetSH, but
it's never called, so no point keeping it around. (Similar methods were removed
in bug 1132184 and bug 1132187.)
It's never defined, and there's a comment in
XPCWrappedNativeProto::CallPostCreatePrototype() explaining how
PostCreatePrototype() doesn't have an associated "want" check.
Instead of the principal object, we use the command line object which is
another XPCOM object with classinfo that has an attribute, a method and
a constant.
The other option, of course, is to just define an "expando slot count" constant
in the header and then static_assert it has the right value once the
ExpandoSlots enum is declared.
Add a typedef on top of mozilla::Vector to define the TranscodeBuffer which owns
the encoded content of a Script / Function.
This modification renames JS_EncodeScript, into JS::EncodeScript, and change its
prototype to have a JSContext, a TranscodeBuffer, and a Handle on a script that
we want to encode.
Similar modifications are made to JS_EncodeInterpretedFunction, and the Decode
variant of these.
This patch allows specifying an OriginAttributes when creating a sandbox
using Components.utils.Sandbox() by specifying an originAttributes
member on the options dictionary.
If an OA is specified in this way, it is used for creating codebase
principals from the string arguments passed to the function. Otherwise,
if one or more principals are passed in the array argument to Sandbox(),
the OA of the principal(s) is used to construct codebase principals from
the strings inside the array. In this case, we check to make sure that
all of the passed principals have the same OA, otherwise we'll throw an
exception.
In case no explicit OA is specified and no principals are passed in the
array argument, we create the codebase principals using a default OA.
Entries should end up getting cleared out from this table before the
value dies, so let's just make the reference strong so that any
mistakes will result in leaks and not use-after-frees.
Using smart pointer classes with PLDHashtable is a little
questionable, and I don't want to convert this one hash table to
nsTHashtable, so I use manual addref and release.
MozReview-Commit-ID: Kfg9veS6r11
--HG--
extra : rebase_source : 865ab48c2cf67546dd705cf79f8873efe695ac5c
Also clean up some random comments for code that was deleted earlier.
MozReview-Commit-ID: 8JQx0FAH8wA
--HG--
extra : rebase_source : 614bda8caf0647ff0220986904ac6fb5fd4573a8
This patch is similar to bug 1288870.
Strong references:
- XPCCallContext::mSet: Like XPCNativeInterface, this only roots it
when |mState >= HAVE_NAME|, and again this only requires changing
SystemIsBeingShutDown().
- XPCWrappedNativeProto::mSet and XPCWrappedNative::mSet. These become
RefPtrs.
- stack: AutoMarkingNativeSetPtr become RefPtr<XPCNativeSet>. This
lets me eliminate some uses of AutoJSContext. This is the bulk of the
patch.
Weak references:
- mNativeSetMap. This reference gets cleared in the dtor. This
requires bug 1290239 to actually find the entry for removal.
- mClassInfo2NativeSetMap. The reference is in the value for this hash
table, and we don't have the key in the set dtor. Fortunately, the
only code that adds to this table is
XPCNativeSet::GetNewOrUsed(nsIClassInfo* classInfo), which in turn is
only called by GetNewOrUsed(nsIClassInfo* classInfo). This code
creates a new XPCWrappedNativeProto, which (with my patch) holds a
strong reference to the set that has been added to the table. This set
is never changed or released until the dtor for the proto, which calls
ClearCacheEntryForClassInfo(), removing the entry from the
hashtable. Thus, the lifetime of the set is always going to be longer
than the lifetime of the entry.
Other notes:
- Like XPCNativeInterface, this class uses placement |new| that
requires a special destruction function, which with my patch is hidden
away in the refcounting code.
- This patch delete a bunch of marking/sweeping code from
XPCJSRuntime::FinalizeCallback(), because the lifetimes are managed by
the refcounting now. Some of the marking code is left behind to be
cleaned up in a later patch.
- I didn't see any methods that had XPCNativeSet** outparams.
- MOZ_COUNT_{CTOR,DTOR}(XPCNativeSet) is not needed because it is now
refcounted.
MozReview-Commit-ID: 7oTorCwda1n
--HG--
extra : rebase_source : 0c477e18c405e4ea88393279cf8bea62c5b0f4c7
The new name makes the sense of the condition much clearer. E.g. compare:
NS_WARN_IF_FALSE(!rv.Failed());
with:
NS_WARNING_ASSERTION(!rv.Failed());
The new name also makes it clearer that it only has effect in debug builds,
because that's standard for assertions.
--HG--
extra : rebase_source : 886e57a9e433e0cb6ed635cc075b34b7ebf81853
If we are inserting an XPCNativeSet into a NativeSetMap, and we failed
to find it, then the insertion should not have found some other set
there already.
Additionally in this case, the hash value of a XPCNativeSetKey for the
set we are inserting should be the same as the key we used to insert
the set into the map. If this property does not hold, then we can't
use Remove() to remove the set from the map. This condition would have
caught the error that part 1 fixes.
MozReview-Commit-ID: 23v37GzA4XV
--HG--
extra : rebase_source : 4dca7ffc436f53214eb2927bc1ff2f71927f7ac3
The current hash function fails to take into account that all
XPCNativeSets have nsISupports as their first element.
MozReview-Commit-ID: 7B8TPVnaM7I
--HG--
extra : rebase_source : a357f88a7d54aa1c9f58b6d429d4a5bbaaa13e80
We crash sometimes if we fail to add. We should always crash, because
we don't properly attempt to handle failure, and it would be nice to
get proper OOM-annotated crash reports.
MozReview-Commit-ID: EGgYxPdUSky
--HG--
extra : rebase_source : 92faf09c52452089b32cc430c04568b81e677f74
This patch removes checking of all the callback calls in memory reporter
CollectReport() functions, because it's not useful.
The patch also does some associated clean-up.
- Replaces some uses of nsIMemoryReporterCallback with the preferred
nsIHandleReportCallback typedef.
- Replaces aCallback/aCb/aClosure with aHandleRepor/aData for CollectReports()
parameter names, for consistency.
- Adds MOZ_MUST_USE/[must_use] in a few places in nsIMemoryReporter.idl.
- Uses the MOZ_COLLECT_REPORT macro in all suitable places.
Overall the patch reduces code size by ~300 lines and reduces the size of
libxul by about 37 KiB on my Linux64 builds.
--HG--
extra : rebase_source : e94323614bd10463a0c5134a7276238a7ca1cf23
Now we can see what is really happening in Hash: first hash the
interfaces from the base set, if any, then hash the additional
interface, if any.
Note that this function is wrong when mBaseSet is null. This will be
fixed in bug 1290239.
MozReview-Commit-ID: KaxQ57ofO1D
--HG--
extra : rebase_source : 42012878839adb2e36580480abce7d9708288db4
Both cases first hash together all of the existing interfaces.
MozReview-Commit-ID: AnUF5uPSPpN
--HG--
extra : rebase_source : 43ac016974d3ee4dfbd92361348aeeae5b6a793c
Now I take advantage of knowing that any new interface is always being
added to the end of the set.
Further cleanup of Hash() will happen in the next patch.
MozReview-Commit-ID: EoESTOfIOr
--HG--
extra : rebase_source : 8471391d23e3ff27a27156f55badbef3d1a4118b
There are three cases for a key, represented by the three ctors:
1. mBaseSet is non-null, mAddition is null.
2. mBaseSet is null, mAddition is non-null.
3. Both mBaseSet and mAddition are non-null.
In the three places that use the value of mPosition, condition 3
holds, so the key must have been constructed using the third ctor. For
this ctor, mPosition is equal to mBaseSet->GetInterfaceCount(), so I
substitute the value and eliminate the field.
This makes a check in NewInstanceMutate() trivially false, so I
eliminated that, too.
MozReview-Commit-ID: 1SOF6GyccU7
--HG--
extra : rebase_source : e215da19d77d6f88c216a48a07b9450c4d0e12bb
The mPosition field will be eliminated in a later patch.
MozReview-Commit-ID: EyVYZGgUWrH
--HG--
extra : rebase_source : 229ec989485bdd3ef86670a7c7db4149281a8d79
This explicitly represents the three types of keys that are used:
1. A key for an existing set.
2. A key for a new set with one interface added.
3. A key for an existing set with one new interface added at a
specified position.
MozReview-Commit-ID: Ctw41EymHbd
--HG--
extra : rebase_source : d7ce7d608a3d09df752313116c99bc2079d15a13
XPCNativeSet::GetNewOrUsed() and ::NewInstanceMutate() essentially
take XPCNativeSetKeys as arguments, but pass them around
unboxed. Passing around the keys explicitly will allow later changes
to enforce stronger invariants on keys.
MozReview-Commit-ID: CyQU3bUGinq
--HG--
extra : rebase_source : 5cdc651c1e4b9566dccd61b66de5e2bb8d6f33f5
The patch is generated from following command:
rgrep -l unused.h|xargs sed -i -e s,mozilla/unused.h,mozilla/Unused.h,
MozReview-Commit-ID: AtLcWApZfES
--HG--
rename : mfbt/unused.h => mfbt/Unused.h
XPCNativeInterface::Mark(), Unmark() and IsMarked() don't do anything
any more, so anything that calls them can be deleted. This removes the
only use of XPCCallContext::CanGetInterface(), so delete that, too.
MozReview-Commit-ID: 4w3aPTVXNDI
There are four classes that call Root() on XPCNativeInterface, and
thus keep interfaces alive. Each of these gets converted to use a
RefPtr:
1. XPCCallContext. This could be on some kind of hot path, but the
FindMemberCall involves various string operations and hashtable
lookups, so adding a single AddRef shouldn't matter. One weirdness
here is that the context only roots the interface when |mState >=
HAVE_NAME|. With a RefPtr<>, this requires nulling out
mInterface. Fortunately, in most cases where it moves from rooting to
non-rooting, it already does this. The one case it does not is in
SystemIsBeingShutDown(), so my patch adds that.
2. XPCNativeSet. This holds an array of interfaces in a weird
placement new array at the end of the object. I wasn't sure how a
non-POD class would interact with the way the array is handled with
casting, so I manually AddRef and Release things put into or removed
from the array.
3. AutoMarkingNativeInterfacePtr simply becomes RefPtr<>. This is the
bulk of the patch, in terms of number of lines changed.
4. Similarly, the one AutoMarkingNativeInterfacePtrArrayPtr becomes
nsTArray<RefPtr<>>. This is the last use of the auto marking array
class, so I deleted it.
Here are some other notes on what the patch does:
- XPCNativeInterfaces are created with placement new. This requires a
special version of refcounting that calls DestroyInstance, defined in
the previous patch. The GetNewOrUsed methods used to explicitly call
DestroyInstance(), but with refcounting this is no longer needed.
- The Mark() etc. methods are gutted so they don't do anything and
mMarked is removed because it is no longer used. The methods will be
cleaned up in later patches in this bug.
- Interfaces are removed from mIID2NativeInterfaceMap in the dtor
instead of during sweeping, requiring an extra hash table lookup.
- All of the methods that can create a new interface (NewInstance,
GetISupports, GetNewOrUsed) now return an already_AddRefed<>, which
gives some static checking that we don't accidentally fail to hold
onto a newly created interface.
MozReview-Commit-ID: CrlH1ENAzvr
Like part 2, this patch is to work around a false GC hazard in
~XPCNativeInterface in part 4. This hazard is around the return value
of WrapperFactory::PrepareForWrapping(), because ~XPCCallContext might
call ~XPCNativeInterface. The fix is to pass the return value into a
mutable handle. Unfortunately, this function is used in the JSAPI, so
JS minor engine changes are also needed.
MozReview-Commit-ID: GwFxmrXFXmb
This is to work around false GC hazards in ~XPCNativeInterface in part
4 of this bug. Putting RefPtr<XPCNativeInterface> on the stack means
that ~XPCNativeInterface can get called in various places, and the GC
hazard analysis does not understand the virtual methods involved, so
it assumes they might possibly GC.
This fixes one hazard by taking a jsid handle argument. The callers
already pass in handles, so no other changes are needed.
MozReview-Commit-ID: LpNpTlujpkm
XPCNativeInterface::Mark(), Unmark() and IsMarked() don't do anything
any more, so anything that calls them can be deleted. This removes the
only use of XPCCallContext::CanGetInterface(), so delete that, too.
MozReview-Commit-ID: 4w3aPTVXNDI
There are four classes that call Root() on XPCNativeInterface, and
thus keep interfaces alive. Each of these gets converted to use a
RefPtr:
1. XPCCallContext. This could be on some kind of hot path, but the
FindMemberCall involves various string operations and hashtable
lookups, so adding a single AddRef shouldn't matter. One weirdness
here is that the context only roots the interface when |mState >=
HAVE_NAME|. With a RefPtr<>, this requires nulling out
mInterface. Fortunately, in most cases where it moves from rooting to
non-rooting, it already does this. The one case it does not is in
SystemIsBeingShutDown(), so my patch adds that.
2. XPCNativeSet. This holds an array of interfaces in a weird
placement new array at the end of the object. I wasn't sure how a
non-POD class would interact with the way the array is handled with
casting, so I manually AddRef and Release things put into or removed
from the array.
3. AutoMarkingNativeInterfacePtr simply becomes RefPtr<>. This is the
bulk of the patch, in terms of number of lines changed.
4. Similarly, the one AutoMarkingNativeInterfacePtrArrayPtr becomes
nsTArray<RefPtr<>>. This is the last use of the auto marking array
class, so I deleted it.
Here are some other notes on what the patch does:
- XPCNativeInterfaces are created with placement new. This requires a
special version of refcounting that calls DestroyInstance, defined in
the previous patch. The GetNewOrUsed methods used to explicitly call
DestroyInstance(), but with refcounting this is no longer needed.
- The Mark() etc. methods are gutted so they don't do anything and
mMarked is removed because it is no longer used. The methods will be
cleaned up in later patches in this bug.
- Interfaces are removed from mIID2NativeInterfaceMap in the dtor
instead of during sweeping, requiring an extra hash table lookup.
- All of the methods that can create a new interface (NewInstance,
GetISupports, GetNewOrUsed) now return an already_AddRefed<>, which
gives some static checking that we don't accidentally fail to hold
onto a newly created interface.
MozReview-Commit-ID: CrlH1ENAzvr
This adds a heap allocation in
XPCNativeScriptableSharedMap::GetNewOrUsed() on the fast
path. Hopefully that code is not hot enough for it to matter. I could
work around this if needed, but it would be ugly.
mNativeScriptableSharedMap has a weak pointer to
XPCNativeScriptableShared. I moved this removal from
XPCJSRuntime::FinalizeCallback() to the dtor.
There are two types of scriptable: one is a dummy one created in
GetNewOrUsed() to do a lookup, and the other is a fully filled out
one. The dummy one is not added to the hashtable, and may have had its
name stolen if we created a new scriptable. The latter makes it so
that you crash if you try to look it up in the hashtable anyways, so
this patch only looks up fully filled out scriptables.
This patch also removes MOZ_COUNT_CTOR/DTOR because they are not
needed for refcounted classes.
Stop destroying mScriptableInfo in XPCWrappedNative's
SystemIsBeingShutDown(), because that will end up destroying
XPCNativeScriptableShared, while their js::ClassOps are still in use
by JS objects. This matches the existing behavior, which does not
sweep these ScriptableShared during shutdown. (This came up in opt
xpcshell tests.)
MozReview-Commit-ID: GeG0pAYqXpR
This patch makes most Run() declarations in subclasses of nsIRunnable have the
same form: |NS_IMETHOD Run() override|.
As a result of these changes, I had to add |override| to a couple of other
functions to satisfy clang's -Winconsistent-missing-override warning.
--HG--
extra : rebase_source : 815d0018b0b13329bb5698c410f500dddcc3ee12
I could clean up ArrayAutoMarkingPtr more, but it is going to be
removed entirely in bug 1288870.
MozReview-Commit-ID: Jyjc2ZfvF3i
--HG--
extra : rebase_source : d7954ab821722b26fe5fc4f5ddc319dd824c6879
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
--HG--
extra : rebase_source : bd5e7bf9010acf83ccab8ce6cce77a557ad76196
The basic idea is that we assume the invariant that the "obj" argument is never
gray if "existing" is null (and add asserts to that effect). Starting from that
assumption, terrence and I audited all the return paths to ensure that gray
objects are never returned. We found a few places, generally after crossing
compartments with UncheckedUnwrap, where we could have gray things and inserted
corresponding calls to ExposeObjectToActiveJS.
If "existing" is passed in, all bets are off: both "obj" and "existing" can be
gray and can get returned from here. But the only caller that passes "existing"
doesn't allow the return value to escape, so it's actually safe to do this.
Also convert some NS_PRECONDITION in NativeSetMap.
MozReview-Commit-ID: IU9C5oXKvGK
--HG--
extra : rebase_source : 5fc36e95667d42a1c0cdfb9bbbf99a7ea008bf34
Also, use NS_PTR_TO_UINT32 instead of NS_PTR_TO_INT32 because it is not
undefined.
Get rid of the optimization of 0 ^ x which required a comment.
MozReview-Commit-ID: HPz5VgRnLN1
--HG--
extra : rebase_source : a4602964ff739c4e37aaa5883e6ed667bff1a963
XPCNativeSetKey has a huge comment about this weird hack it does,
where it tags the first 16 bytes with a magic value. The purpose of
this seem to be that PLDHashtable used to require that the Match()
operation handle both the desired "key" type and the actual entry type
(NativeSetMap::Entry in this case), with the latter needed for
resizing. However, that duality in the match operation has not been
needed since bug 374906, which landed in 2007, so this class can be
greatly simplified.
IsAKey() can be replaced with true, which simplifies some hash
operations.
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
Also contains folded version of the following patches that have to land at the same time with enabling the new implementation (or be backed out at the same time, if it comes to that):
Add Promise checks to test_xrayToJS.xul. r=bholley
Change Promise debugger hook tests to use Promise ctor instead of makeFakePromise. r=shu
Change DOM interface tests to assume Promise is an ES builtin, not a DOM one. r=bz
Remove some PromiseDebugging references. r=bz
Adapt promise rejections test to new xray-unwrapping error. r=bz
Fix expectations in browser_timelineMarkers tests. r=tromey
Also contains folded version of the following patches that have to land at the same time with enabling the new implementation (or be backed out at the same time, if it comes to that):
Add Promise checks to test_xrayToJS.xul. r=bholley
Change Promise debugger hook tests to use Promise ctor instead of makeFakePromise. r=shu
Change DOM interface tests to assume Promise is an ES builtin, not a DOM one. r=bz
Remove some PromiseDebugging references. r=bz
Adapt promise rejections test to new xray-unwrapping error. r=bz
Fix expectations in browser_timelineMarkers tests. r=tromey
