1346008 - Custom tabs/web apps: Decide session on store behaviour

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, enhancement)

Description

[Jan Henning [:JanH]]

Custom tabs currently share the same Gecko browsing session, window and profile as normal tabs, so they get included in the session store data as well and possibly restored as normal tabs afterwards.

We should decide on the desired UX behaviour and then see how we can go about implementing that.

Comment 1

[Jan Henning [:JanH]]

We've already got a flag on the Gecko side thanks to bug 1303362, so in principle we could just use that to exclude custom tabs if we wanted to.

Comment 2

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Jan, I suppose you're working on it?

Comment 3

[Jan Henning [:JanH]]

In bug 1351808 I'm going to do the simple thing and just exclude those tabs from being written to disk or appearing in the list of recently closed tabs. The patch for that should be relatively trivial, but I've been busy with bug 1351739 and 1352997 in the last few days - once I've got those bugs out of my way, I'll take care of it. I'm moving the priority setting to that bug.

We can then repurpose this bug if we want to do anything more advanced, which is probably somewhat more complicated as
- custom tabs/web apps run in their own activity, so we can't just automatically restore them the moment Firefox launches as there's no such thing as a "background activity restore"
- if we can't restore them automatically, then how else?
-- do we surface them elsewhere in the UI for manual restoring by the user
-- even if we've been OOM killed/closed by the user, the task switcher might still have web app/custom tab entries lying around . How do we match those up to any session store data we might have?
--- Once the previous session has been restored, the old data is discarded and overwritten by fresh data recorded from the new session (which also contains all restored tabs, thereby preserving continuity for normal tabs), so how should we handle custom/web app tab data, which is not automatically restored into the new session? Maybe move them to a closed custom tab/web app tab data pool (a bit similar to how closed tabs are stored) and then if we get an intent with FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY and cannot find an already opened tab (see the implementation for bug 1352997 - will put it up for review shortly), we first fall back to the stored session store pool of former custom/web app tabs before opening a new tab).

Comment 4

[Jan Henning [:JanH]]

(In reply to Jan Henning [:JanH] from comment #3)
> Maybe move them to a closed custom tab/web
> app tab data pool (a bit similar to how closed tabs are stored) and then if
> we get an intent with FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY and cannot find an
> already opened tab (see the implementation for bug 1352997 - will put it up
> for review shortly), we first fall back to the stored session store pool of
> former custom/web app tabs before opening a new tab).

Just had a flash of inspiration that a more workable idea might be to store the session store data for the currently active tab of a custom tab/web app activity as part of its savedInstanceState data.

Comment 5

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.