This is more consistent with other setters, and lets us handle the null frameLoader
case a bit more simply.
Differential Revision: https://phabricator.services.mozilla.com/D16370
--HG--
extra : moz-landing-system : lando
Alternatively, we could check for mInitialized in `AsyncTabSwitcher.logState` before accessing
the getter. But this matches an existing pattern for other browser getters that rely on the
frameLoader existing, and will support other callers that hit this case.
Differential Revision: https://phabricator.services.mozilla.com/D16368
--HG--
extra : moz-landing-system : lando
Note, we only pass the relevant IV across the IPC boundry. I.e. if the crypto
scheme is cenc we do not pass a constant IV (this is only used by cbcs), and
only pass per sample IVs. For cbcs we do the converse. This means in the CDM
child we're only receiving one IV, which should be appropriate for whatever
scheme (this is similar to how Chromium handle IVs being passed to the CDM).
The CDM child side now writes pattern information to samples it's preparing for
CDM.
With these changes we should be passing all the information required to handle
cbcs to the CDM.
Differential Revision: https://phabricator.services.mozilla.com/D16459
--HG--
extra : moz-landing-system : lando
During review of bug 1458538, :bz noted that our event dispatching code could be
simplified by using DOMEventTargetHelper::DispatchTrustedEvent. As this was not
done during that bug, driveby fix here while we're making other changes.
Differential Revision: https://phabricator.services.mozilla.com/D14571
--HG--
extra : moz-landing-system : lando
Driveby change to bring our logging here in line with out other logging.
Depends on D14488
Differential Revision: https://phabricator.services.mozilla.com/D14489
--HG--
extra : moz-landing-system : lando
The arguably most interesting bit of state of BrowserApp/GeckoApp, namely the
currently open tabs, are living partly in Gecko and partly in the Tabs
manager singleton, the lifetimes of both of which are tied to the lifetime of
the app process.
If the whole process has been killed, things are simple: Neither the Tabs
manager nor Gecko know anything about any tabs and we simply restore them
through the session store if enabled.
If GeckoApp is however being restored into an app process in which it had
already executed earlier on, meaning that we have some open tabs, it relies on
the savedInstanceState in order to correctly reconnect its GeckoView instance
with the correct previous GeckoSession.
We can however end up in a state where we don't have a savedInstanceState (e.g.
because the user swiped away the BrowserApp activity in the task switcher), but
the app process keeps running throughout (if another activity of ours is still
present in the task switcher, e.g. a custom tab, or else if a service is active,
then standard Android keeps the process running even if the user swipes away an
activity).
In that case, if GeckoApp is subsequently recreated, the Android UI sees all the
Android-side tabs in the Tabs manager, and Gecko in fact still has the Window
open that is containing all those tabs, but without the savedInstanceState
GeckoApp doesn't know anything about that Window and proceeds to open a fresh
session instead.
This means that all previous tabs will appear white and unresponsive, while
freshly opened tabs will load, but they won't be correctly saved in the session
store, their context menu isn't working, etc., because we're not really
expecting to handle multiple Gecko-side Windows.
To fix this, we disable automatic state-saving for GeckoApp's GeckoView instance
and instead do it manually, so we can keep another reference to the saved state
in GeckoApplication, and therefore are able to retrieve it from there for as
long as the app process keeps running.
Differential Revision: https://phabricator.services.mozilla.com/D16393
--HG--
extra : moz-landing-system : lando
Currently, when operating with scalars, if a call to internal_GetScalarByEnum (or its keyed variant) return an error, then a warning will be logged. If one of the requested scalars is expired, this could lead to an unwated flood of logs. With this change, the return of the function is checked, and if it is NS_ERROR_NOT_AVAILABLE (i.e. expired scalar), then no warning is issued.
Differential Revision: https://phabricator.services.mozilla.com/D16392
--HG--
extra : moz-landing-system : lando
The added crashtest still crashes on Android verify runs (TV) for
unknown reasons, so skip it.
Differential Revision: https://phabricator.services.mozilla.com/D16395
--HG--
extra : moz-landing-system : lando
Needs to be explicitly declared in case we start targeting Android P.
It's unclear to what extent this is really required when *not* using Android's
network stack directly, but at least with Firefox, some things definitively use
it, e.g. favicons. As we're a browser, we need to allow access to arbitrary
pages, so just generally white-list it.
Differential Revision: https://phabricator.services.mozilla.com/D16408
--HG--
extra : moz-landing-system : lando
We weren't checking this value and it was causing compiler warnings. Instead
this change means we check the value and log an error if init has failed.
Differential Revision: https://phabricator.services.mozilla.com/D15519
--HG--
extra : moz-landing-system : lando
Not much changed in the interface:
- CDM initialization takes a use hardware codecs arg, we pipe this through, but
don't do anything more with it in the clearkey CDM.
- The CDM should call the hosts OnInitialized() when it's initialized. This is
done is now done in the clearkey CDM once the session management is ready, as
that is the last thing done during init.
Aside from the above, it's just updating interface usage. While the new CDM
interface adds support for different encryption schemes, this is not handled
here and will be done in follow up bug 1516673.
Differential Revision: https://phabricator.services.mozilla.com/D15518
--HG--
extra : moz-landing-system : lando
Using track_id 0 is forbidden by the mp4 spec, however, some sites still serve
media using this track_id. We've been using the 0 track ID to trigger special
handling in the MoofParser where we will parse multiple tracks, and this led us
to be tolerant of tracks using this reserved id (though we likely had some bugs
due to this).
Since sites are using this track_id, and as other browsers (and Firefox until I
broke this) tolerate such media, we should too. In order to do so correctly, we
should no longer us track_id=0 as a special case in the MoofParser, and instead
have an explicit flag, which is what this patch does.
Differential Revision: https://phabricator.services.mozilla.com/D16428
--HG--
extra : moz-landing-system : lando
Because older versions of Firefox auto-select a profile if there is only one in
the database when running dev-edition which uses its own profile we create a
default for normal channels to use. Currently the browser code is responsible
for doing this but it uses a bad heuristic for deciding when to do that. It's
much easier to do it from the profile manager when the dev-edition profile is
created.
Differential Revision: https://phabricator.services.mozilla.com/D16117
--HG--
extra : moz-landing-system : lando
Currently nsAppRunner is responsible for choosing or creating a profile to use
at startup. It then has to create a reset profile if necessary and lock the
selected profile directories. But these latter things are done in different
places of the selection code and done in different ways, sometimes we delay
while trying to get the lock, sometimes we don't.
This patch moves the profile selection part of the code to its own function so
that then we only have to have one place that does the profile reset and
locking logic.
It makes a lot of sense to have the selection code live in the profile service.
It can use information from the database load to help make the choices and it
also means that we can expose the profile selection code through xpcom allowing
it to be easily automatically tested. It will also be more important for future
patches for the dedicated profiles feature.
Differential Revision: https://phabricator.services.mozilla.com/D16116
--HG--
extra : moz-landing-system : lando
Brian Grinstead
Bryce Van Dyk
Andrew Halberstadt
Jason Orendorff
Andreas Pehrson
Eitan Isaacson
Narcis Beleuzu
Dave Townsend
Florin Strugariu
Glenn Watson
Dzmitry Malyshau
Lina Cambridge
Jan Henning
Andrew McCreight
Kaio Augusto de Camargo
Ting-Yu Lin
Dão Gottwald
Csoregi Natalia
Noemi Erli
John Lin
Geoff Brown
Ehsan Akhgari