1352999 - Custom Tab: Same page/URL is opened in different tabs in Nightly

Status: RESOLVED FIXED

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

Description

[Sorina Florean [:sflorean]]

Environment: 
Device: Huawei Honor (Android 5.1.1);
Build: Nightly 55.0a1 (2017-04-02);

Steps to reproduce:
1. Open a web page by custom tabs;
2. Tap on three dots menu and "Open in Nightly";
3. Go back to app and repeat step 2 for 4-5 times.

Expected result:
Same link is opened in the same tab.

Actual result:
Same link is opened in different tabs.

Notes:
This is not implemented in Chrome but it will be more user friendly to have just one tab with one content in browser if we perform the same steps.

Comment 1

[Rachelle Yang [:ryang][[e-mail]]]

Hi Jack, 

Can you please help us verify and clarify the symptom if this has anything to do with UX design??

Thank you very much !

Comment 2

[Rachelle Yang [:ryang][[e-mail]]]

as discussed , the symptom is UX design. 
In current design, when returning back, opening browser via custom tab will go back to custom Tab page. 
While in Chrome, when returning back, opening browser via custom tab will go back to the APP page.


It's not a function break, would suggest to update the UX spec in the next stage implementation for 2nd signoff.

Hi Joe, Could you please share your ideas per PM's perspective?

Thank you very much!

Comment 3

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

P2 per triage on april12

Comment 4

[Jack Lin[:jacklin]]

Hi, refered to Chrome behaviors, UX suggests,

1. Open a web page by custom tabs;
2. Tap on three dots menu and "Open in Nightly". At the same time, close custom tabs then open a new tab in Nightly;
3-1. If users press Back key directly, go back to the app and delete the new opened tab in Nightly;
3-2. If users switch to other tab then leave Nightly, the new opened tab in Nightly will not be deleted.

so based on the above, we will have just one tab with one content in browser as expected result.

Comment 5

[Jan Henning [:JanH]]

(In reply to Jack Lin[:jacklin] from comment #4)
> Hi, refered to Chrome behaviors, UX suggests,
> 
> 1. Open a web page by custom tabs;
> 2. Tap on three dots menu and "Open in Nightly". At the same time, close
> custom tabs then open a new tab in Nightly;

Closing and reopening will lose the whole state of the tab (session history, scroll position, form input, ...). We cannot avoid this when switching to a different browser, but as long as we remain within Firefox, we should keep the tab open and just switch activities (which would also side-step the problem of duplicating the tab.

Once bug 1348686 (plus possible follow-ups) is implemented, this would be trivial to do, although it would simplify things if the menu just offered to "Switch to full version of <Firefox/Beta/Nightly/Fennec/...>" instead of a generic ACTION_VIEW, as we could then just directly switch the tab's type to trigger the switch to the full UI. If we want to keep the menu generic [1], something could probably be rigged up using intent extras, though.

As for 3-1, custom tab and web app tabs are technically externally opened tabs, so reaching the beginning of session history while pressing back will close the tab. How to make sure that in that case we'll be returning to the original app I've no idea, though - I'm not really familiar with the intricacies of Android's activity/task history handling [2].

[1] Although e.g. "Open link in new tab" from the context menu isn't - pressing "Switch" from the context menu will - when bug 1351739 has landed - always take you to the full UI of whatever Firefox version you're viewing the custom tab in.
[2] If we've gone from custom tabs to full UI, I assume that the custom tabs activity will be lying around in Android's activity stack somewhere between our current activity and the app that originally launched the custom tab.

Comment 6

[Julian Chu [:walkingice]]

Yes I agree with that we should keep scrolling position when switching to full UI. Discussed with Jack, for now we could just close CustomTabsActivity once user clicked "Switch" option. And file a new bug to implement what you said (base on bug 1348686).

for the appendix 1, I think we don't have to keep the menu generic. Then it also related to bug 1355735

Comment 7

[Julian Chu [:walkingice]]

Attachment: Bug 1352999 - Close activity if user asks to open page in full browser

Once user click "Open in browser" from menu, we are going to open a tab
in full browser, and close this activity. Therefore we won't have two
tabs which confuse user.

Review commit: https://reviewboard.mozilla.org/r/129940/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/129940/

Comment 8

[Sebastian Kaspari (:sebastian; :pocmo)]

Comment on attachment 8857898 [details]
Bug 1352999 - Close activity if user asks to open page in full browser

https://reviewboard.mozilla.org/r/129940/#review132486

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0ac4960227da
Close activity if user asks to open page in full browser r=sebastian

Comment 10

[Iris Hsiao [:ihsiao]]

https://hg.mozilla.org/mozilla-central/rev/0ac4960227da

Comment 11

[Joe Cheng [:jcheng] (please needinfo)]

per team's conversation last week, this isn't a blocker for this feature. 
clearning NI flag as it's resolved