818336 - Returning to a running webapp should not switch tabs

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Web Apps (PWAs), defect, P1)

Description

[Wesley Johnston (:wesj)]

Bug shows in the twitter web app. Open it and click a link to a story inside. The page loads inside the twitter webapp. Now press home and launch twitter again. We open to the original twitter page (because we were passed it in the launch intent), but the opened page is still behind it in a hidden tab. I think we should probably open back to the page you had open. Back should then return you to the normal twitter page.

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

We should look into opening links in external browsers, not open new tabs in the web app. We could use a "if same domain, open in web app" or even use a whitelist (for persona).

CC'in Myk for advice on what desktop does.

Comment 2

[James Hugman [:jhugman] [@jhugman]]

The experience on PhoneGap: 

Changing window.location to a file:// URL is honored (this would be the same as a same domain request).
Changing window.location to anything else forces mobile safari to be opened.

For OAuth logins, the usual practice is for the developer to manage the opening of a Child Browser – which is a separate Activity/UIViewController which pops over or replaces the current screen. Child Browser is a PG plugin, https://build.phonegap.com/docs/plugins#childbrowser

Unfortunately, lots of clients want to avoid leaving their app just to open a link, so you end up with clients demanding their developers build a fake web browser in within their app. This is down to switching back from browser to app being ungood on iOS devices.

For OAuth logins on Android, there is some native support for OAuth in Play Services. http://android-developers.blogspot.ca/2012/09/google-play-services-and-oauth-identity.html

Comment 3

[Myk Melez [:myk] [@mykmelez]]

(In reply to Mark Finkle (:mfinkle) from comment #1)
> We should look into opening links in external browsers, not open new tabs in
> the web app. We could use a "if same domain, open in web app" or even use a
> whitelist (for persona).
> 
> CC'in Myk for advice on what desktop does.

In the case of link targets, we intentionally open most links with targets in a new tab/window of the app to support Persona and other major auth providers, many of whom load in new tabs/windows; but we open target="_blank" in the default browser on all platforms (desktop, Android, and B2G) to support the "external link aggregator" usecase (Facebook, Twitter, lifestreamers, Google News, RSS readers, etc.).

(The detailed discussion for all platforms is in Desktop bug 752666, but also see Android bug 766802 and B2G bug 769254.)


For window.open() the behavior is undefined, per discussion in bug 752666 that we don't understand its usage well enough (see sicking's comments in particular).  But we should revisit and consider opening window.open(url, "_blank") in the browser while opening windows with any other "name" argument in a new tab/window of the app.


I'm not sure what window.location does, but I think it opens the URL in the same window/tab of the app, showing an "origin toolbar" if the origin of the URL is different from the origin of the app.  (I think this too is necessary to support one of the major auth providers, whose UI flow is to have the app redirect to the auth provider, which then redirects back to the app after authenticating the user.)  But this seems fairly undefined as well, and we could consider doing what PhoneGap does.


It isn't clear from the bug description how Twitter is opening this tab, but if it's using <a target="_blank">, then the link should already open in the browser, per bug 766802, and this is a regression.

If it's using window.open(url, "_blank"), on the other hand, then we should consider enhancing the runtime to open such links in the browser automatically, so it works the way Twitter expects.

And if it isn't setting the link target or window name to "_blank", but it should be, then this is a developer evangelism issue.


But if Twitter does want these links to open in a tab of the app, and for other apps that want the same thing (like those opening auth providers in tabs), Wes's suggestion in comment 0 seems spot on: when the user switches back to an app that was on a particular tab when the user switched away from it, the app should remain on the tab it was on, regardless of how the user switched back to the app (from the task switcher, by tapping the homescreen icon, etc.).

Comment 4

[(not currently active) Ted Mielczarek]

We should look into duplicating the behavior of App Tabs on desktop. They seem to do the right thing in most cases.

Comment 5

[Erin Lancaster [:elan]]

For the Twitter-specific case:
We have the capabilities in Gecko to provide support to do this so part of this providing specifics to webapps developers. 

For the general world: Android WebRT should look into helping to prevent this from happening (we always open a fresh tab) but we should look at this with UX. We should also look at what Desktop does. 

Next Steps: we are going go over the desktop experience vs the mobile one and come up with a solution together with UX.

Comment 6

[Myk Melez [:myk] [@mykmelez]]

The desktop experience is not particularly relevant, since the thing we are calling a "tab" in Android is very different from an App Tab on the desktop.  It is more akin to an Android Activity.

We are overcomplicating this issue; or perhaps we are talking about two different issues.

The issue Wes initially raised in this bug is that switching back to an app does not return the user to the view of the app they were on when they switched away from the app.  And it's fairly obvious that it should, since that is how apps on all multitasking operating systems behave, including native Android apps and desktop apps.  It is an implementation detail that the views happen to be implemented as "hidden tabs."

Above and beyond that basic issue, there may be an additional issue around the circumstances under which a URL opens in a hidden tab vs. the browser.  We defined that behavior with respect to <a target="..."> (on Android, desktop, and Firefox OS), but we could have gotten it wrong; and we left it undefined with respect to window.open(url, "..."); so we might have more work to do.  But that would be a separate issue.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #6)
> And it's fairly obvious that it should, since
> that is how apps on all multitasking operating systems behave, including
> native Android apps and desktop apps.

Erm, I'm aware of two exceptions:

1. Google's Play Music on Android doesn't always return you to the same view (although it usually does, and it isn't yet clear to me why it doesn't in some cases).

2. Firefox on Windows opens a new browser window instead of returning you to the existing browser window when you double-click its icon in Windows' File Explorer.

Neither seems particularly relevant, but I suppose there might be a reason for the Android web runtime to return to a different view of an app when its homescreen icon is tapped.  So maybe it's worth having UX take a look at this.

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

Wes - Let's implement what you describe in comment 0. We should not open the webapp URL/Tab when returning to the webapp. We should return to the last tab that was active.

I think this means we should skip the code that looks for an existing tab when launching a webapp. Either the webapp has never been started, in which case the tab does not exist and needs to be created, or the webapp has been started and we should show the currently active tab (which may or may not be the webapp "main" page).

I don't think we should remove all the code for showing an existing tab if one exists, just stop doing it for webapps. Make sense?

I will file a new bug for dealing with window.open style APIs.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

filed bug 826325 for window.open discussions

Comment 10

[Wesley Johnston (:wesj)]

Attachment: Patch v1

In these cases, we wind up going through the command line handler. This just has us do nothing if Fennec is already running and the url is a webapp (which should result in us showing the last open tab).

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 697519 [details] [diff] [review]
Patch v1


>diff --git a/mobile/android/components/BrowserCLH.js b/mobile/android/components/BrowserCLH.js

>+        if (!pinned) {
>+          browserWin.browserDOMWindow.openURI(uri, null, Ci.nsIBrowserDOMWindow.OPEN_NEWTAB, Ci.nsIBrowserDOMWindow.OPEN_EXTERNAL);
>+        }

No braces needed

Comment 12

[Wesley Johnston (:wesj)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0fc37d11f9af

Comment 13

[Wesley Johnston (:wesj)]

Comment on attachment 697519 [details] [diff] [review]
Patch v1

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Webapps
User impact if declined: Users can leave tabs stranded in the background forever
Testing completed (on m-c, etc.): Landed on mc today. Tested locally a lot.
Risk to taking this patch (and alternatives if risky): Very low risk. This code is run by everyone, but we're basically only changing behaviour for webapps.
String or UUID changes made by this patch: None.

Comment 14

[Ed Morley [:emorley]]

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

Comment 15

[Ed Morley [:emorley]]

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

Comment 16

[Ed Morley [:emorley]]

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

Comment 17

[bhavana bajaj [:bajaj]]

Comment on attachment 697519 [details] [diff] [review]
Patch v1

Low risk, android only , helps with webapps, approving on aurora.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/7a41feae49ff