Closed Bug 1347585 Opened 3 years ago Closed 3 years ago

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

Categories

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

53 Branch
All
Android
defect

Tracking

()

RESOLVED INVALID

People

(Reporter: droeh, Assigned: droeh)

References

(Blocks 1 open bug)

Details

Swiping to kill a custom tab does not close the associated tab, instead leaving it open in Fennec.
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.
Blocks: 1346004
Blocks: 1300570
I wonder whether the same issue applies to web apps as well - does swiping them away leave the tab open in Gecko, too?
Blocks: 1285858
(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.
Priority: -- → P2
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.
No longer blocks: 1346004
Depends on: 1352997
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.
Using latest nightly I couldn't reproduce it.
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.
No longer relevant, this only applied to the GeckoApp-based custom tabs.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.