Unfortunately, `EventChainVisitor` does not grab the `nsPresContext` with
`RefPtr` by itself. Therefore, there is no guarantee of the lifetime without
checking the origin when its subclasses are instantiated. This patch changes
it and subclasses to `MOZ_STACK_CLASS` since only `EventDispatcher::Dispatch()`
creates them in the stack with given `nsPresContext`. Additionally, it's
already been marked as MOZ_CAN_RUN_SCRIPT_BOUNDARY`. Therefore, the
`nsPresContext` instance has already been guaranteed its lifetime by the
caller. For making this fact stronger, this patch marks their constructors
as `MOZ_CAN_RUN_SCRIPT`. Therefore, nobody can create those instances without
guaranteeing the lifetime of `nsPresContext` and `dom::Event`. Note that
it may look like that `mPresContext` of `EventChainPostVisitor` is not
guaranteed. However, `EventChainPreVisitor` which gives `nsPresContext` to it
is also a stack only class. So, it won't be deleted before
`EventChainPostVisitor` instance.
Differential Revision: https://phabricator.services.mozilla.com/D30010
--HG--
extra : moz-landing-system : lando
These tests need to be disabled to get a green run on the Android x86_64
test platform. The failures in toolkit/components/extensions are
concerning and definitely require follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D29843
--HG--
extra : moz-landing-system : lando
The call in VRFrameData::LazyCreateMatrix is not needed because
aRetval.set(aArray) ends up calling into Heap::get() which does a read barrier
and exposes.
The call in nsXULPrototypeScript::Compile is not needed because initializing
the AutoJSAPI will guarantee that the global of the Realm it enters, which is
what we're examining here, will be exposed.
The call in Promise's CreateNativeHandlerFunction is not needed because the
object being passed in was always just-created into a stack Rooted.
The call in MIDIMessageEvent::GetData is not needed because it's always working
with a just-created object. Also, mData is a Heap, so there will be a read
barrier anyway before anyone gets at the value.
The call in PrototypeDocumentContentSink::ExecuteScript is not needed because
the AutoEntryScript will guarantee that the global of the Realm it enters is
exposed. And the JSAutoRealm is not needed either, because we're in that Realm
already.
Differential Revision: https://phabricator.services.mozilla.com/D29720
--HG--
extra : moz-landing-system : lando
We store newInnerGlobal in a Rooted, so as long as we expose on all codepaths
that assign to that variable (which with this patch we do, typically via
GetWrapper() calls), there's no need to expose explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D29718
--HG--
extra : moz-landing-system : lando
Marking GetGlobalJSObject and GetGlobalJSObjectPreserveColor final and inline
on inner/outer windows allows compilers to de-virtualize and inline them, which
makes them just as fast as calling FastGetGlobalJSObject is now (in the case of
GetGlobalJSObjectPreserveColor; GetGlobalJSObject has to do the gray-unmarking,
which is a bit more work).
In WindowDestroyedEvent::Run we want to switch to GetGlobalJSObject(), because
we want to root the object and hence should unmark gray.
In nsGlobalWindowInner::RunTimeoutHandler we likewise want to unmark gray. The
AutoEntryScript constructor likely did that already, but it's not that
expensive when it doesn't need to do any work.
Differential Revision: https://phabricator.services.mozilla.com/D29711
--HG--
extra : moz-landing-system : lando
Consumers that just care about this boolean state should use this instead of
getting the JSObject* directly.
Differential Revision: https://phabricator.services.mozilla.com/D29705
--HG--
extra : moz-landing-system : lando
This can be used in things like assertions or some other rare circumstances
where not exposing the object to active JS is OK.
Differential Revision: https://phabricator.services.mozilla.com/D29704
--HG--
extra : moz-landing-system : lando
Promise::Compartment is unused.
The callers that want to call AutoJSAPI::Init can pass it an nsIGlobalObject,
which is actually _more_ efficient, since passing a JSObject just gets an
nsIGlobalObject from it and passes that.
Differential Revision: https://phabricator.services.mozilla.com/D29703
--HG--
extra : moz-landing-system : lando
It's possible for a malformed mp4 to contain invalid sample description index in
fragments, that do not reference any sample description entries found in the
header. E.g. the header may contain 2 sample description entries (which should
be indexed with indices 1 and 2), but for a fragment to contain an index to 4.
Instead of asserting in this case we should gracefully fail.
Bug 1547328 plans to add logging for this case, so we have a means to still
detect failures here from bad files.
Depends on D29733
Differential Revision: https://phabricator.services.mozilla.com/D29734
--HG--
extra : moz-landing-system : lando
Add an mp4 with a bad sample description index to crashtests. When samples in a
fragment are encountered, they should reference a sample description entry found
in the mp4 header. However, it's possible that the index contained in the
fragment may refer to an entry that doesn't exist in the header, as in this
file.
Differential Revision: https://phabricator.services.mozilla.com/D29733
--HG--
extra : moz-landing-system : lando
Jan-Ivar Bruaroey
Ryan Hunt
Andreea Pavel
Masayuki Nakano
Ryan VanderMeulen
Mihai Alexandru Michis
Honza Bambas
Paul Bone
Kartikaya Gupta
Sebastian Hengst
Frederik Braun
Liang-Heng Chen
Coroiu Cristina
Cosmin Sabou
Nico Grunbaum
John Dai
Jan Varga
Olli Pettay
Byron Campen [:bwc]
Andrea Marchesini
Geoff Brown
Zibi Braniecki
Dorel Luca
Boris Zbarsky
Bryce Van Dyk