833607 - Press-and-hold Back should show a back stack rooted in source activity

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Richard Newman [:rnewman]]

Some Android apps extend the Back button. E.g., tap and hold in TouchDown, and you get to choose Mail, Calendar, etc.

And of course, Firefox on desktop shows a menu of previous pages if you hold down the Back button.

We should do the same thing on Android. And if you came to Firefox from another activity, *the earliest entry should be to pop the whole stack and return to that activity*.

This saves users from the "hammer the back button so I can get back to Twitter" problem.

(Related: Bug 751915.)

Comment 1

[Richard Newman [:rnewman]]

Ah, Bug 454880.

Then let's morph this to be: when a tab was opened from another activity (e.g., Twitter, mail client), *root the back stack in that app*, complete with icon and name.

Comment 2

[Christian Vielma (IRC :cvielma)]

Hey Richard, no problem to take this bug, but I don't understand very well what's the problem.

If I'm in Twitter and open a link in Firefox, then I go back it should get back to Twitter? Because right now this is the normal behaviour. 

Let me know!

Comment 3

[Richard Newman [:rnewman]]

Hey Christian,

Here's the scenario. You open a link from Twitter. It's a multi-page article, so you click through five links. Now you want to go back to Twitter.

Before your recent work, you had to tap the home button precisely six times, waiting for things to be responsive each time.

Now you can press-and-hold and pick the first entry (assuming you didn't go so far that the menu gives up!), and then press back again.

I want to get rid of that second press.

I contend that the first entry in a tab opened from another activity should be *the other activity*, complete with icon and name. So you'd see:

   [Page 5   ]
   [Page 4   ]
   [Page 3   ]
   [Page 2   ]
   [Page 1   ]
   [* Twitter]

Tapping that activity would eliminate the tab and pop ourselves off the app stack, precisely as if the user had already descended all the way through the back stack.

(Though I observe that most of the time, tabs I open in Firefox from other apps *don't* get cleaned up when I go back to the previous app: Bug 751915. There might be a bug there that you'll fix here.)

This satisfies most of the desires of the "give me back my quit button!" crowd (dumping the whole activity stack of the browser, going right back to the previous app), and adds a nice splash of discoverability (I wonder how many users hit Home then relaunch Twitter?) and a delightful dash of usability.

Comment 4

[Paul [pwd]]

Shouldn't double (maybe triple) tap of back simply take you back? I remember reading something about utilising "bounce back"? It seems like a far saner implementation than polluting the back stack with third-party apps.

Comment 5

[Richard Newman [:rnewman]]

(In reply to Paul [sabret00the] from comment #4)
> Shouldn't double (maybe triple) tap of back simply take you back? I remember
> reading something about utilising "bounce back"?

"Bounce back" usually describes the rubberbanding behavior of draggable interfaces. Do you have a link to a different usage?


> It seems like a far saner
> implementation than polluting the back stack with third-party apps.

I can only speak for myself, but I sometimes tap back twice to hop back two pages, or do it by accident. I favor deliberate choice over a surprising response to a reflex: I can imagine howls of rage as Firefox appears to quit and the previous app reopens because a user double-tapped back by mistake.

And I don't think it's "pollution": in some specific circumstances, reflecting the Android activity stack, the back stack is rooted in an activity rather than in about:home. Just as if you came from twitter.com instead of Twitter.

There is precedent for this: take the share bar, for example, which includes an app's icon and name.

"Go back to the app that sent me here" is (I assert) a really common act for anyone who uses Firefox as their default browser; I think we can agree on that. So the question becomes: what behavior is most discoverable, least intrusive, and most likely to result in user delight?

Comment 6

[Christian Vielma (IRC :cvielma)]

Ah ok, understood! It is really an a good improvement in usability. I'm not quite sure how to do it, but I'll take look about it. 

Other thing I would suggest is that instead of showing the list with "Go Back to Twitter"  at the beginning you could just double tap the back button and  that would show you a message like "Go Back to <app>"  and when you tap on the message you override all the history you have been navigating, so no necessity of showing the browsing history. 

Also, what would happen if a person opens the link in Twitter and then navigates the multi-link page opening each link in a different tab? (I often do that, I feel it faster) Each tab will have a different "history"  that might not show you the opening application, so I think it would be a good idea to return to the opening app using the double tap in the back button to accomplish this globally in the browser. What do you think?

The only doubt that I have about this approach is what happens to the opened tabs in the browser after I go back to the opening app. What if I had other tabs before the opening application? Which ones should I close?

Comment 7

[Richard Newman [:rnewman]]

(In reply to Christian Vielma (IRC :cvielma) from comment #6)
> Ah ok, understood! It is really an a good improvement in usability. I'm not
> quite sure how to do it, but I'll take look about it. 
> 
> Other thing I would suggest is that instead of showing the list with "Go
> Back to Twitter"  at the beginning you could just double tap the back button
> and  that would show you a message like "Go Back to <app>"  and when you tap
> on the message you override all the history you have been navigating, so no
> necessity of showing the browsing history. 

That might work, but I don't know what our UX position is on modal dialogs, and how that applies to desktop and tablet.

Ian?


> Also, what would happen if a person opens the link in Twitter and then
> navigates the multi-link page opening each link in a different tab? (I often
> do that, I feel it faster) Each tab will have a different "history"  that
> might not show you the opening application, so I think it would be a good
> idea to return to the opening app using the double tap in the back button to
> accomplish this globally in the browser. What do you think?

My opinion: at that point you've transitioned to a general browsing session, so it doesn't make sense to try to close tabs (which I think is how we currently behave?), but back-navigation is still helpful. I could see a few approaches:

* Regard this whole interaction with Firefox as being some 'child' of the parent app, and provide some global way of popping the whole app.

* Treat your entry-point tab as a doorway: that tab's history includes the previous app. Of course, hitting Back at top-level with nowhere else to go will also pop the activity, just as it does now.

The former has some advantages (supporting app-back from multiple tabs), at the cost of some slight conceptual muddiness: you lose the conceptual integration of a chain of navigation rooted in some app that opened your browser. That is, the user now has to think about two histories: their navigation history (taps in content) and their app stack (taps in applications).

There's a third way which I think combines the two usefully: include the "referring" app at the bottom of *every* tab's history, presumably with some kind of gentle visual cue that it's not a page. If you follow the simple navigation of launch, tap, tap, tap, go back, then we can close the whole tab. If you do something complex, we just pop the activity.

If you got to Firefox from the launcher, perhaps we show no referring activity, or perhaps we show 'quit'!


> The only doubt that I have about this approach is what happens to the opened
> tabs in the browser after I go back to the opening app. What if I had other
> tabs before the opening application? Which ones should I close?

I think once you start a 'complex' browsing session, by leaving your "entry tab", we should leave your session alone.

Comment 8

[Christian Vielma (IRC :cvielma)]

I'm thinking about it. It seems better the thrid way. 

Although, I kept thinking: what happens if I go to to Twitter and open a link. Then I use the app switcher of Android and go back, now to Facebook, and open another link. And so on... Let's say, each one of these are "complex" browsing sessions. 

Then I close all the applications and start a session in Firefox: I will see a lot of tabs, each one with a different calling application when I query the history? or will I have only "calling app"  for all the tabs? Or since it is a "new session" it shouldn't show anything? Finally, what happens if when in the link opened from Facebook I go to the tab of Twitter?

Just thinking and making suggestions I think maybe this could be solved in two ways (not mutually exclusive):

1.- The "third way" (by rnewman comment7) showing Quit unless there is a referring app, in which case, all the tabs of the current session will show this, no matter what app opened the tab. So "referring app" would be global to the browser and not specifically for each tab.

2.- Maybe the "double tap" I suggested? If there is a referring app it goes back to it, and if not, shows an alert "do you want to quit?" (just for desperate people). 

Anyway, if the user just quit it will go back to the referring app. So maybe what we need is only a "shortcut" for quit?

Comment 9

[Ian Barlow (:ibarlow)]

(In reply to Richard Newman [:rnewman] from comment #7)
> (In reply to Christian Vielma (IRC :cvielma) from comment #6)
> > Ah ok, understood! It is really an a good improvement in usability. I'm not
> > quite sure how to do it, but I'll take look about it. 
> > 
> > Other thing I would suggest is that instead of showing the list with "Go
> > Back to Twitter"  at the beginning you could just double tap the back button
> > and  that would show you a message like "Go Back to <app>"  and when you tap
> > on the message you override all the history you have been navigating, so no
> > necessity of showing the browsing history. 
> 
> That might work, but I don't know what our UX position is on modal dialogs,
> and how that applies to desktop and tablet.
> 
> Ian?

I would prefer to move ahead with rnewman's long press back to see a history list + referring app, it feels like a cleaner interaction to me.

Comment 10

[Richard Newman [:rnewman]]

(In reply to Christian Vielma (IRC :cvielma) from comment #8)

> Although, I kept thinking: what happens if I go to to Twitter and open a
> link. Then I use the app switcher of Android and go back, now to Facebook,
> and open another link.

The app switcher is basically a mechanism for breaking the Android activity stack, so there's not much we can do here to add value.


> Then I close all the applications and start a session in Firefox: I will see
> a lot of tabs, each one with a different calling application when I query
> the history? or will I have only "calling app"  for all the tabs? Or since
> it is a "new session" it shouldn't show anything? Finally, what happens if
> when in the link opened from Facebook I go to the tab of Twitter?

There's only one 'calling app' -- the app that activated the current browser activity via an intent. If you open a link from Twitter, it's Twitter. If you then app-switch to Facebook and click a link, the calling app is Facebook. If you then press Home and launch Firefox, there's no calling app (or rather, it's the launcher).

I'm not sure if there's even a good way to hang on to "Twitter" in a way that we can return to it if it's not the next app in the activity stack.

I'd like to concentrate on the user scenario we're supporting here: it's that you've ended up in the browser after you were doing something elsewhere, and you want to go back to what you were doing.

There are other mechanisms for 'escaping' -- notifications, or hitting Home, or using the app switcher -- so we really just want to be able to shorten the chain of Back taps that you need to get back to where you were going in the usual case.

I don't see a need to track the originating app for each chain of browsing. Then we'd hit edge cases like:

* Open Facebook
* Click a link
* Browse in Fennec
* App-switch to Facebook, navigate around Facebook
* Switch back to Fennec: how do we get back to where you were in Facebook? We aren't even chained into the activity stack in the right way, nor do we have control over Facebook's internal stack.

Our implementation choices here are limited, so it's lucky that the simplest and most usable solution is the most convenient!


> Anyway, if the user just quit it will go back to the referring app. So maybe
> what we need is only a "shortcut" for quit?

If Quit is defined as "pop this activity from the activity stack", then that's exactly what I'm suggesting. I'm simply proposing that as a conceptual framework, users think of the previous app as being somehow tacked on to the start of their browsing history: we hook into the back button to implement browser navigation, so that joins the two concepts. If you keep hitting back, you walk through history and then leave Firefox, so let's put the app you'd return to at the end of the back-menu history list.

Comment 11

[Christian Vielma (IRC :cvielma)]

Yes, currently Quit works as "pop this activity from the activity stack", what should we do then?

Comment 12

[Richard Newman [:rnewman]]

(In reply to Christian Vielma (IRC :cvielma) from comment #11)
> Yes, currently Quit works as "pop this activity from the activity stack",
> what should we do then?

In the past, I've been told that Quit was "exit(0)", which kills other Android features running in the same process. And we removed it a while back.

For now, I suggest chaining back to a referring activity. If there is no such activity, show nothing. We can tweak that behavior after more UX consideration; I'm disinclined to reintroduce Quit without a bunch of buy-in.

Comment 13

[Aaron Train [:aaronmt]]

Just noting in here, see bug 840664; back-button is system reserved on some devices (TouchWiz Nature UX).

Comment 14

[Christian Vielma (IRC :cvielma)]

Should the URL Back button be shown on those devices to solve this?

Comment 15

[Paul [pwd]]

Enable the history on the forward button for all smartphones and then the functionality can be accessed there on Galaxy devices?

Comment 16

[Richard Newman [:rnewman]]

Long-press back is only stolen if Multi App mode is turned on, on my S3, 4.1.2.

Comment 17

[Christian Vielma (IRC :cvielma)]

So, what would be the bottom line for this functionality?

Comment 18

[Richard Newman [:rnewman]]

Attachment: Appearance in fx21

Tap and hold the Back button, and you get a menu like this.

Comment 19

[Richard Newman [:rnewman]]

Sorry, that screenshot was aimed at Bug 454880.

Christian, I don't understand your question. Could you rephrase?

Comment 20

[Christian Vielma (IRC :cvielma)]

Yes, I'm sorry. I see that there are some doubts about this functionality (as how to overcome the problem with TouchWiz), so I would like to know the final decision about how should it work in order to take the bug. 

Thanks!

Comment 21

[Richard Newman [:rnewman]]

(In reply to Christian Vielma (IRC :cvielma) from comment #20)
> Yes, I'm sorry. I see that there are some doubts about this functionality
> (as how to overcome the problem with TouchWiz), so I would like to know the
> final decision about how should it work in order to take the bug. 
> 
> Thanks!

How we overcome problems with Android launchers that steal the back button is kinda outside the scope of this bug.

Let's leave that for Bug 840664, and keep the scope of this bug to extending Bug 454880: if Firefox is launched from an intent, keep a reference to the sender of the intent, and use the sender as the root of our back stack.

There will be nuances around which intents to consider, whether to think of it as the root for the whole browsing session or just the launched tab, etc., but I think this is enough to start with.

Comment 22

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.