Prior bug 1416085, reads were clamped to the content's duration (if known). It appears that the new code relied on MediaCacheReadBlockFromCache to properly account for the end of content.
However, this was not the case, the MediaCache always reads (and write) one full block at a time regardles of the size requested (a block is 32768 bytes).
Rather than clamping in the Read() method as it used to be, we clamp in ReadBlockFromCache as such safety will benefit other callers that would have otherwise also returned garbage reads.
Differential Revision: https://phabricator.services.mozilla.com/D5964
--HG--
extra : moz-landing-system : lando
Always new reasons to remove the first-line frame and this reparenting stuff...
I hope I can get to it.
Differential Revision: https://phabricator.services.mozilla.com/D5075
--HG--
extra : moz-landing-system : lando
If we're trying to detach and reattach the same compositor object for
whatever reason, we should skip it so we don't inadvertently end up not
attaching the object at all.
Differential Revision: https://phabricator.services.mozilla.com/D5608
--HG--
extra : moz-landing-system : lando
A previous patch in this bug made the incorrect assumption that we had disabled
the family safety root detection/importing feature by default. In reality, we
enabled it by default in bug 1282871.
In bug 1487258 we moved enterprise root loading to a background thread so as to
not block the main thread. This patch does the same with the family safety
feature.
Differential Revision: https://phabricator.services.mozilla.com/D5484
--HG--
extra : moz-landing-system : lando
We need the isDOMClass() checks in the Compartment code to pass tests, because
some of the jsapi tests explicitly test those failure codepaths. But not with
DOM objects, which is what we're interested in here.
Differential Revision: https://phabricator.services.mozilla.com/D6047
--HG--
extra : moz-landing-system : lando
The AutoplayPermissionManager might be destroyed before the AutoplayPermissionRequest, so we can't
get the response from request before AutoplayPermissionManager is destroyed.
Therefore, we should manually reject the promise when the inner window is going to be destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D5906
--HG--
extra : moz-landing-system : lando
The reason we hit this assertion is that we still connected to Then() and waited for its result when the resolve or reject
runnable which dispatched by ThenValue can't be executed because the target thread had been shutdown.
Therefore, when XPCOM is going to shutdown, we should disconnect the Then() because it might not have a chance to execute
its resolve/reject method.
Differential Revision: https://phabricator.services.mozilla.com/D5893
--HG--
extra : moz-landing-system : lando
As in Bug 1390583 and Bug 1470993, this will correct them to be external symbols
Differential Revision: https://phabricator.services.mozilla.com/D6044
--HG--
extra : moz-landing-system : lando
These tasks only run on rc release promotion steps, so there is no need to very
the configuration per-project.
Differential Revision: https://phabricator.services.mozilla.com/D5790
--HG--
extra : moz-landing-system : lando
Jonathan Kew
Dão Gottwald
Diego Pino Garcia
Ciure Andrei
Henrik Skupin
Ehsan Akhgari
Bogdan Tara
Coroiu Cristina
Jean-Yves Avenard
Gijs Kruitbosch
Dorel Luca
Logan F Smyth
Robert Helmer
Francesco Lodolo (:flod)
Emilio Cobos Álvarez
Jim Chen
Ryan VanderMeulen
Dana Keeler
Andrew Swan
Jed Davis
Boris Zbarsky
Jan Henning
Jan de Mooij
alwu
Christian Holler
Tom Ritter
Tom Prince