1347585 - Swiping to kill a custom tab leaves the tab open in Fennec

Status: RESOLVED INVALID

(Firefox for Android Graveyard :: General, defect, P2)

Description

[Dylan Roeh (:droeh) (he/him)]

Swiping to kill a custom tab does not close the associated tab, instead leaving it open in Fennec.

Comment 1

[Jan Henning [:JanH]]

Definitively something that should be fixed if we stop custom tabs from showing up in the normal UI, so we don't "leak" Gecko tabs.

Comment 2

[Jan Henning [:JanH]]

I wonder whether the same issue applies to web apps as well - does swiping them away leave the tab open in Gecko, too?

Comment 3

[Oana Horvath [:ohorvath]]

(In reply to Jan Henning [:JanH] from comment #2)
> I wonder whether the same issue applies to web apps as well - does swiping
> them away leave the tab open in Gecko, too?

Yes, it happens the same with web apps: closing the standalone app, leaves the tab opened in Fennec.

Comment 4

[Jan Henning [:JanH]]

Dylan, do you have any ideas here already?

While working on bug 1352997, I've come up with the following concept:
- Going forward from bug 1352997 [1], each custom tab/web app activity will keep track of the tab its supposed to display, even if that activity is in background now and the new foreground activity has already selected a different tab.
- Once bug 1348686 and follow-ups are implemented, tabs can change their type after their creation, meaning they can move between activities. This means that each tab should (via a WeakReference) also track its "owning" activity, so we don't accidentally close a tab that is being displayed in another activity now.

Then, when an activity is destroyed (which sadly we're not guaranteed to be notified about, but I can't think of anything better - onPause is definitively too early and not directly linked to swiping the activity away from the Recents list), it checks whether its previously selected tab still exists and hasn't since moved to another activity. If these conditions hold, then the tab is closed.

[1] Actually each GeckoApp instance keeps track of a "lastSelectedTabId" even now, but the system can get confused sometimes and so cannot be relied upon for closing tabs.

Comment 5

[Dylan Roeh (:droeh) (he/him)]

I don't really have an approach in mind for this; I'm most likely going to prototype a GeckoView based custom tabs client and see how far we can get with that before looking at any non-crash custom tabs bugs. Your idea for handling this sounds pretty solid to me.

Comment 6

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

Using latest nightly I couldn't reproduce it.

Comment 7

[Jan Henning [:JanH]]

How did you check this? We're hiding those tabs in the normal UI, however if you enable session store debug logging, check about:memory, or connect with the WebIDE and look at the open tabs or debug browser.js, you should still be able to see those tabs getting left behind.

Comment 8

[Dylan Roeh (:droeh) (he/him)]

No longer relevant, this only applied to the GeckoApp-based custom tabs.