1300570 - [meta] Separate normal / custom / web app tabs

Status: RESOLVED INVALID

(Firefox for Android Graveyard :: General, defect)

Description

[Jonathan Almeida [:jonalmeida]]

STR:
- Open fennec and observe the current open tabs in the browser.
- Use a sample app[1] to open a tab in the app.
- Once loaded, press back to close the tab.
- Switch back to fennec

Actual results:
- Observe that the page opened in the sample app is loaded as a tab in fennec.

Expected results:
- This tab shouldn't be in the main browser since it was opened in the sample app.

[1]: For my steps, I've used a Hacker News app that supports Custom Tabs: https://play.google.com/store/apps/details?id=com.leavjenn.hews

Comment 1

[Sebastian Kaspari (:sebastian; :pocmo)]

Yep, that's not implemented yet. We need to flag and separate the tabs. That's something we will need for PWAs too.

Comment 2

[Julian Chu [:walkingice]]

Attachment: video for similar problem

Got similar problem. I can open Fennec-opened-page in another sample app.

Comment 3

[Julian Chu [:walkingice]]

The way I reproduce

1. Open Fennec to open any page
2. Go to sample app such as Hacker News App
3. open any link in Sample-App
4. switch to Fennec, open tabs list. We will see the tab opened from Sample-App, remove it
5. switch back to Sample-App

Comment 4

[Sebastian Kaspari (:sebastian; :pocmo)]

Yeah, currently we just keep a list of all tabs in Tabs.java. We need to start to separate them, so that we have browser tabs, custom tabs and later web app tabs in separate lists.

Comment 5

[Sebastian Kaspari (:sebastian; :pocmo)]

Tom, Jan: I wonder whether one of you would like to implement this (or work together?). You both have worked with our tab code extensively. Right now we have one big pool of tabs. However to implement the custom tabs API [1] and add support for web apps we need to have separate groups (maybe some kind of type system?).

To give you an example: If you enable the custom tabs API and open a website in a custom tab from a third-party app then this tab will show up in Fennec too. This shouldn't happen. However we want to be able to switch from a custom tab to a full-featured browser - so we need some kind of hand-off where tabs switch from one group to the other. And all this will affect session restore etc. too. As you can see this can get complex and this bug might very well be a meta bug...

Anyways, this is an important building block for some upcoming features - would you like to take it?

[1] https://developer.chrome.com/multidevice/android/customtabs

Comment 6

[Jan Henning [:JanH]]

Would somewhat de-singletonifying the Tabs object with one Tabs object per group of tabs we want to keep separate be something you had in mind?

> And all this will affect session restore etc. too.

I've no idea what our long-term plans are here - if it's something like bug 889100, I guess that would mean that each tab category would get its own XUL browser <window> as well (although that would slightly complicate moving tabs between categories, since we then have to transfer the <browser>s as well), so we could separate the session store behaviour based on the tab's owner window.

In the meantime, we could probably fudge something by setting additional attributes on the individual JS tab objects...

Comment 7

[Sebastian Kaspari (:sebastian; :pocmo)]

(In reply to Jan Henning [:JanH] from comment #6)
> Would somewhat de-singletonifying the Tabs object with one Tabs object per
> group of tabs we want to keep separate be something you had in mind?

For now I thought it would be enough to keep the Tabs singleton and expose a filtered list of tabs to the browser. Custom Tabs and also Web Apps are more or less activities that only show a single tab. So we'd just need things like select/remove (for switching to the activity or closing it). But if working on this bug reveals that a different strategy makes more sense then go ahead.

> > And all this will affect session restore etc. too.
> 
> I've no idea what our long-term plans are here - if it's something like bug
> 889100, I guess that would mean that each tab category would get its own XUL
> browser <window> as well (although that would slightly complicate moving
> tabs between categories, since we then have to transfer the <browser>s as
> well), so we could separate the session store behaviour based on the tab's
> owner window.

You can try custom tabs in Nightly. Go to "Settings -> Advanced -> Experimental Features" and enable it. After that make sure that Nightly is set as your default browser. After that custom tabs from third-party apps should open in Fennec. Unfortunately some apps hard-code Chrome. This is a little test app from our Taipei team:
https://github.com/walkingice/CustomTabsLauncher

You'll notice that the tab that opens in the custom tab will be open at the same time in the browser (it's actually the same tab). So the goal of this bug is to not have it show up in the browser.

bug 1315937 is going to introduce a menu item to open a website in a custom tab in the browser. Instead of launching an intent and reloading the page we could "just stop filtering it from the list of tabs" and it will show up in the browser again.

Does this make sense?

A first version might be just "a little hack" in the Tabs class. However from there we need to see how this affects session restore, or synced tabs, or history.

Comment 8

[Nevin Chen(Not active on Bugzilla)]

Hi Jim
In desktop I can have multiple windows. And each one has it's own tabs. I can restore them according to which window I'm in. 
May I know if there's a similar behavior for me to do that in Fennec? Maybe in http://searchfox.org/mozilla-central/source/widget/android/nsWindow.cpp ?

imho, I think the best way is to use the full browser app. Thus we don't have to worry about hiding PWA tabs and seperate them. Please correct me if I'm wrong, I think it adds bunch of complexity instead of benifits.

Comment 9

[(inactive) Jim Chen [:jchen] [:darchons]]

One possibility is to use GeckoView to support multiple windows for pwa/custom tabs (each GeckoView creates its own window), but currently GeckoView is not quite ready yet.

Comment 10

[James Willcox (:snorp) ([e-mail]) (he/him)]

This isn't a problem now that we use GeckoView for custom tabs