Open Bug 1346008 Opened 3 years ago Updated 3 years ago
Custom tabs/web apps: Decide session on store behaviour
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.
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.
Depends on: 1303362
Summary: Custom tabs: Decide session on store behaviour → Custom tabs/web apps: Decide session on store behaviour
Jan, I suppose you're working on it?
Priority: -- → P1
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).
Depends on: 1352997
Priority: P1 → --
(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.
You need to log in before you can comment on or make changes to this bug.