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
This can cause 1proc tests to fail because no decoder ends up supporting
a format. The particular case was enabling Vorbis decoding on RDD.
Differential Revision: https://phabricator.services.mozilla.com/D29766
--HG--
extra : moz-landing-system : lando
The assert removed here can be triggered by malformed mp4s that lack certain
crypto info (the sinf box), but that still indicate samples are encrypted via
sample description entries.
I plan to follow up the removal here by adding logs so we have some way to
detect this case. This will be done as part of bug 1547328.
Depends on D29692
Differential Revision: https://phabricator.services.mozilla.com/D29693
--HG--
extra : moz-landing-system : lando
Add an mp4 with a mangled tenc box to the crashtests. This file has been fuzzed
and appears to have had the tenc box for its second track changed to a '.enc'
box, which means it cannot be parsed. The tenc box is contained in the sinf box,
so this will bust the sinf parse. We should tolerate such bad files and not
assert and/or crash.
Driveby add a comment to another line in crashtests list to make it clear the
bug the file originally relates to.
Differential Revision: https://phabricator.services.mozilla.com/D29692
--HG--
extra : moz-landing-system : lando
