Co-authored-by: Sebastian Kaspari <s.kaspari@googlemail.com>
Co-authored-by: Christian Sadilek <christian.sadilek@gmail.com>
- The WebView instance is long-lived, as it's referenced in
SystemEngineSession, and we want to be able to keep engine
sessions around for the lifespan of the application.
- The WebView instance is created by the engine and using its
context (the application context).
- The EngineView, rendering engine sessions and WebViews,
is created using an activity context.
- The problem was that when the activity and EngineView were
destroyed, the WebView was not being detached and still
referenced the parent which referenced the activity context,
which would then not get gc'ed.
- We now detach the WebView when the EngineView is destroyed
and only destroy the WebView when the session is closed.
- This will allow re-using of engine sessions and their
WebViews in different activities and allow for proper
destruction.
The main change here is that EngineSessionHolder can now hold an EngineState and this state
is used when we need to create an EngineSession (which will clear the state). This has the
following advantages:
* When restoring we can just attach the EngineState and do not need to create the
EngineSession immediately. With that we do not load all the EngineSessions and everything
at once. Initially only the selected EngineSession will be created and loaded. That will
make the restore faster and use less resources when restoring a lot of sessions.
* (Not in this commit, for a follow-up) It allows us to close EngineSession instances and
just keep the EngineState around until we need the EngineSession again. That's something
we could do in low memory situations or when there are just too many sessions/tabs open
to be performant (e.g. only keep the last recently used EngineSession instances around).
This patch simplifies how the history tracking delegate is set, and removes unnecessary
complexity around the history tracking feature.
It's important to set the delegate before the first engine session instance is created.
There are multiple points in time when that might happen:
- if we have a SessionSnapshot, we'll restore early on and create bunch of engine sessions
- we'll may create a 'default' engine session via one of the multiple use cases which use
SessionManager
- we may create an engine session at any other point in time, as soon as we have an engine
instance, by manually invoking 'createSession' method.
In short, applications aren't constrained in how they create sessions, and various components
may create sessions at different points in time, depending on their lifecycles, how things
are configured to behave, etc.
If we want to guarantee that our engine sessions always have a history tracking delegate instance
set, simply setting it on the 'defaultSettings' object guarantees that in the most straightforward way.
This also makes problems around lazy initialization of HistoryTrackingFeature irrelevant, since that
feature is now gone.
This patch removes the feature-storage, since the only thing it contained was a delegate implementation.
Underlying HistoryStorage implementations might be blocking on IO (Rust Places, room),
or migth be non-blocking (in-memory). A Deferred return type for get* methods makes
it convenient to wrap both regular and `async` operations. Use of 'suspend' functions
serves the same role for write* methods.
This change makes it obvious at the engine call-site that the underlying implementation
might suspend, at which point we can wrap calls in `runBlocking` or use another coroutine builder.
This is a workaround for Firefox for Fire TV to play DRM content automatically.
Eventually we want to implement this API in a way that the app (or another component) can
handle those requests. See: https://github.com/mozilla-mobile/android-components/issues/1157
The goal is to provide our engines with ability to query for browser history
and to record visits and page metadata updates (e.g. title changes).
GeckoView's APIs are still being implemented in https://bugzilla.mozilla.org/show_bug.cgi?id=1494713,
so this works from the implementation notes. WebView's APIs are well known.
History delegate is optional. Absence of it in settings when configuring an engine as akin to
disabling history tracking.
This patch explicitly doesn't provide an implementation of a delegate.
