Now that the AudioFocusAgent keeps monitoring all relevant tab events and
notifies the MediaControlService as necessary, we can revert to only running the
service when actually required to show the notification and keep us alive during
(background) media playback.
MozReview-Commit-ID: KV6ars2BbMW
--HG--
extra : rebase_source : 3d3681b960605c4c4e4caff0e96804b6b4770d7c
We're not a bound service and the MediaSession is initialised during onCreate(),
so its release conversely needs to happen during onDestroy().
For consistency, we also move unregistering of the HeadSetStateReceiver into the
shutdown helper method.
Additionally, while things seem to have worked anyway in practice (possibly be-
cause we're only using the MediaSession within the same process?), technically
you're supposed to explicitly activate the session before using it.
MozReview-Commit-ID: 1HDva7p2ljF
--HG--
extra : rebase_source : b665d4d08b1a30898235ac3e1ffeab460fbb3b5b
At the moment the MediaControlService is structured such that it is started
shortly after Firefox has launched. Then, it registers a Tab event listener and
starts listening for various, mainly media-related tab events, in response to
which the playback notification is then shown or hidden as appropriate.
This setup has the drawback that the service itself has to remain running all
the time, even when we're not actually showing the notification, so Firefox now
keeps showing up as a "Running service" even when in background and not doing
anything interesting.
It is however relatively easily possible to move the tab event tracking into a
different class that won't require a service to stay alive, and set the Media-
ControlService's state (and at the same time start it if necessary) through a
set of special intent actions.
As the AudioFocusAgent is
a) alive for the whole lifetime of the application and
b) already interacting with the MediaControlService,
we designate it as the class responsible for this.
MozReview-Commit-ID: 1CzBpC1LTuZ
--HG--
extra : rebase_source : ef846bc1c52cb55fb1dfcdf05f2705f92358244e
In practice we've already been using the application context anyway, but this
way makes it more explicit.
With that out of the way, we can also silence the linter here, since the Static-
FieldLeak check is only really relevant when holding onto non-Application
contexts.
MozReview-Commit-ID: CYOs8MPnlcN
--HG--
extra : rebase_source : 5187034e3276b25f7871adb8f4a0ec1aeb25bd02
Fix some style inconsistencies, plus things Android Studio is complaining about.
MozReview-Commit-ID: BdO0UTTsidi
--HG--
extra : rebase_source : 7b7a6c6b2b5d1a43e5e69c03c7bb678087244553
On macOS, the paths for the special directories `GreD` (Resources) vs. `GreBinD`
(MacOS) are different. On other platforms, they are the same.
With scalar loading for artifact builds, we need to load a file from
`Resources`, so `GreD` should be used for this case.
MozReview-Commit-ID: 91JFwOISQCk
--HG--
extra : rebase_source : d94df1acc4c7b9d6fe217fb0621950eb2c53351d
Instead of adding and immediately closing a tab, which carries the risk that we
catch a session store file that was written just in-between those two
operations (although part 1 means that we should be able to handle this safely
now), we just reload the current tab.
MozReview-Commit-ID: JbiH8rmbbwJ
--HG--
extra : rebase_source : 540ad903c3b1424b4603233044f5908cc7a09fea
If we can assume that a layer being composited has an APZC at index i if and
only if the frame metrics at index i is scrollable, then we can do the
transformations in the next patch without any change in functionality.
MozReview-Commit-ID: FRkvhwdd3nh
--HG--
extra : rebase_source : f1bee292305730079b3208e447330028c1a40727
This makes more sense in APZCTreeManager, but is exposed back to
AsyncCompositionManager via APZSampler. This also makes the APZ code
better encapsulated since the method API exposed on APZSampler doesn't
need to take a AsyncPanZoomController; it can just take the
LayerMetricsWrapper instead.
MozReview-Commit-ID: 9yJJd3x8VhN
--HG--
extra : rebase_source : b6f81116183810df158d8cce72891bb2db458355
Before, we would initialize LRUCache on the first instance of
calling the Timer Precision Reduction functions. We would both
allocate and initialize it, and call ClearOnShutdown.
ClearOnShutdown can only be called on the Main Thread, but it
just so happened that we always did that, so there was no
problem. Now that we are not calling precision reduction for
system callers, we were initializing on a non-main-thread and
we need to avoid that.
In the future, we could reduce memory use IF we are not using
the timer precision reduction functions by figuring out how
to initialize this lazily but still on the main thread. For
now, because we are using the timer precision reduction
functions, doing so would not save us any memory.
MozReview-Commit-ID: 6YGeAlCPReZ
Because plugin state in the content now contains blocklist state, and is updated
when the blocklist updates, we don't need to ask the parent if we're checking
blocklist state. All the consumers should now be asking the plugin code directly,
so we can stub out the last API here. We should look at removing the content side
of this service entirely, but that's something for a follow-up bug.
MozReview-Commit-ID: DE8s8RwT42r
--HG--
extra : rebase_source : 06fbc304e99679f55c7cdc52404cd138221feca3
This changes the pluginreg.dat format to include the blocklist state.
There is now only the saved blocklist state in a plugin tag instance, rather than
looking it up from in there using the blocklist service, so it was renamed from
mCachedBlocklistState to mBlocklistState. We pass the 'right' state to the plugin
instance when the plugintag is constructed. If we don't have state, we mark it as
unblocked.
mCachedBlocklistStateChanged was never read so it's being removed.
Bug 1439519 adds a 'blocklist-loaded' notification that is fired once the blocklist is loaded.
The plugin host implementation will listen to this in the parent process and update the
blocklist state of all the plugins, and broadcast changes to the child process, just like when
we update the blocklist from the server. We now also avoid re-sending plugin content to the
content processes if the plugin state hasn't changed as a result of the blocklist having been
loaded.
Finally, because new plugins should still get an up-to-date blocklist state, and
telemetry should get up-to-date data about which plugins are and aren't enabled
once we have that data, we ensure that once we've loaded the blocklist async,
we schedule an idle task to parse it and consider it loaded.
All this means that plugin blocklist information could be mistaken between the points where
a new plugin is installed and we first run Firefox with the new plugin, and the point where
we load the blocklist. Given the trade-offs, that size of window (tiny) seems OK, also given
that there's already a much larger window in blocklist updates (which only happen once every 24h).
MozReview-Commit-ID: 1gsojRkUzTw
--HG--
extra : rebase_source : 4709916b4674ada54f8a495fd2d16fcef8c58d20
We use a wrapper script when compiling with MSVC to parse the
/showIncludes output and thereby generate a Makefile dependency
fragment. This fragment enables us to do correct and faster incremental
builds. But the cost of invoking the wrapper script can be significant;
it's an extra process or two to launch for every single compilation.
Instead, let's have clang-cl generate the dependencies directly, which
should be somewhat faster.
When we fail to generate an image key for an image, it is likely because
the image container is empty. This is not a fatal error, it just means
we haven't produced a frame yet. We should be using NOT_READY instead of
BAD_IMAGE as a result. This is important because reftests rely upon
these error codes to know whether or not they should wait; it could
cause intermittent failures.
If an image container is empty, it will not produce an image key for use
with WebRender. This is generally not a sign of failure because the
producer likely has yet to populate the container with data. As such, we
should not immediately attempt to fallback. In fact, fallback can make
things worse in this situation, as we will create an image client to
send over the data, but then find that there is no data to share (or
find that there is, due to a race with the producer thread, and use
image clients when we could use shared surfaces).
Summary: It uses two node bits that can be better suited for something else.
Reviewers: xidorn, smaug
Bug #: 1444905
Differential Revision: https://phabricator.services.mozilla.com/D709
MozReview-Commit-ID: HIPDtHm6xpM
