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
gNeckoChild is only accessed on main thread, so we should use NS_IsMainThread to see whether we should access gNeckoChild or not.
This patch also makes UDPSocketChild::Bind return NS_ERROR_NOT_AVAILABLE when mBackgroundManager is null.
Differential Revision: https://phabricator.services.mozilla.com/D29658
--HG--
extra : moz-landing-system : lando
The Content Security Policy tests were handling the smaller android preload
values that were #defined on Android by setting media.preload.default=2. Now
that we're detecting whether we're on cellular or not, and the android
emulators that our tests run on emulate a cellular connection, just setting
media.preload.default is no longer enough.
So set media.preload.default.cellular=2 in the CSP mochitests instead of
media.preload.default, to make the CSP mochitests pass in the Android
emulators.
Differential Revision: https://phabricator.services.mozilla.com/D29617
--HG--
extra : moz-landing-system : lando
We're allowed to take some liberties as to what the default value and behaviour
we assume for the 'preload' attribute on HTMLMediaElement by the spec. On
desktop we assumed preload="metadata", while on mobile we assumed the default
of preload="none" to save data. On mobile we also assumed that preload="auto"
meant preload="metadata".
I think it makes sense to instead of always assuming that data on Android is
always expensive, we can instead detect if we're running on a cellular connection,
and preload frugally then, otherwise aggressively.
Differential Revision: https://phabricator.services.mozilla.com/D26235
--HG--
extra : moz-landing-system : lando
Normally when downloading media data we throttle the download only if we're
ahead of the read cursor more than the "readahead limit", and if we estimate
that the connection is fast enough that we'll be able to download at a rate
fast enough to playback in real time if we resume it later.
On mobile we additionally override this so that we always throttle the download
once we're ahead of the read cursor by the readahead limit. This is to save
data. I think we can relax this to only do this override if we're on a
cellular connection; if we're on WiFi we can assume data is cheap.
Differential Revision: https://phabricator.services.mozilla.com/D26234
--HG--
extra : moz-landing-system : lando
In GeckoView the nsINetworkLinkService doesn't work in the content process, as
we don't seem to have an AndroidBridge there, so just maintain the network
connection type on the ContentChild.
(I had considered keeping this on the NeckoChild, but the creation of that is
initiated from the content process side, and there's not an easy and clean way
to have the parent process send us the connection type after construction of
the NeckoParent, other than have the NeckoChild request it either
synchronously, or doing it async and hoping it's not asked for the value before
the response comes in.)
Differential Revision: https://phabricator.services.mozilla.com/D26232
--HG--
extra : moz-landing-system : lando
Detect content process that already has connection to the RDD process
and don't attempt to relaunch or needlessly call
RDDProcessManager::CreateContentBridge. Calling CreateContentBridge
unnecessarily causes churn by recreating RemoteDecoderManagerParents.
Differential Revision: https://phabricator.services.mozilla.com/D29013
--HG--
extra : moz-landing-system : lando
Zibi Braniecki
Dorel Luca
John Dai
Boris Zbarsky
Bryce Van Dyk
Michael Froman
Nika Layzell
Byron Campen [:bwc]
Gijs Kruitbosch
Daniel Varga
Kershaw Chang
Julien Cristau
Gurzau Raul
Myk Melez
Ehsan Akhgari
Brindusan Cristian
Bogdan Tara
Chris Pearce
Perry Jiang
Thomas Nguyen
Jonas Allmann
Valentin Millet