1219343 - Default to "Always restore" for "Tabs" settings pref

Status: VERIFIED FIXED

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

Description

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

I noticed this was defaulted to "Don't restore after quitting Fennec" the other day. I propose we set the default to "Always restore".

I understand that there's some that might not want to restore their tabs. But I feel like the sensible default here is to leave it on. I think it aligns better with user expectation and that way we aren't putting the onus on our users to dig through settings to be able to benefit from "restoring" their tabs.

Is there some context I'm missing here?

Comment 1

[:Margaret Leibovic]

mfinkle/bnicholson, what's the history here?

Comment 2

[Brian Nicholson (:bnicholson)]

I've pushed for this a few times myself, but I was always overruled. I'd love to see this finally happen!

I think the main counterpoint was that it hurts startup perf since it has to load a page instead of the home panels. We do that anyway for background kills, though, so I'm not convinced that's a good reason. Also worth noting that both Chrome, the stock browser, and Firefox on iOS always restore.

Comment 3

[Brian Nicholson (:bnicholson)]

Some bug history here: https://bugzilla.mozilla.org/show_bug.cgi?id=801412#c9

Comment 4

[:Margaret Leibovic]

(In reply to Brian Nicholson (:bnicholson) from comment #3)
> Some bug history here: https://bugzilla.mozilla.org/show_bug.cgi?id=801412#c9

Thanks for the link. It looks like discussion in there just petered out.

I agree with Anthony's point about user expectation, I would think auto-restore would be the default. If UX/product think this is the right call, I'm on board.

From a performance perspective, we should make sure the session restore path is fast no matter what, since we already need to do this when we're OOM killed, and that's when users would definitely expect to get back to their previous state quickly.

Comment 5

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Any thoughts here Barbara?

Comment 6

[Barbara Bermes [:barbara] - NI please!]

That's a tricky one, I think it's not defaulted for Desktop (not saying that we should follow Desktop here) but for some reason, I feel we should keep it as it.

There are so many things we have no or little control over when it comes to optimizing performance on mobile. This is an example where we can guide the user to experience a better performance by not enabling this by default. So my gut feeling is to keep it as it.

However if you can convince me that
a) the performance won't suffer much 
b) people have asked for it
c) and you know me by now :) have probes

Comment 7

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

(In reply to Barbara Bermes [:barbara] from comment #6)

> However if you can convince me that
> a) the performance won't suffer much 

Performance shouldn't be affect much at all. We only load tab stubs. We do not load the page until the tab is selected.

> b) people have asked for it

android.not_a_preference.restoreSession3 is flipped a non-trivial amount.

> c) and you know me by now :) have probes

We should add a simple boolean histogram probe.

This would also be a nice "ask" during onboarding: "Would you like to have your previous set of tabs restored whenever Firefox starts?"

Comment 8

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

FTR: I also set my Firefox to always restore tabs from last time.

Comment 9

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Barbara Bermes [:barbara] from comment #6)
> That's a tricky one, I think it's not defaulted for Desktop (not saying that
> we should follow Desktop here) but for some reason, I feel we should keep it
> as it.

This is an interesting one because it sits squarely in the "mobile context" bucket for me. I believe even Desktop is looking to surface a "Restore # tabs" button more prominently in their UI. I'll bet they have some telemetry on that button (as it currently sits) too!

And I think people are so used to "killing apps" in their Recents that this seems to me like it would be much more valuable in a mobile context.

> There are so many things we have no or little control over when it comes to
> optimizing performance on mobile. This is an example where we can guide the
> user to experience a better performance by not enabling this by default. So
> my gut feeling is to keep it as it.

I agree, but it seems from comment 7 like there isn't actually a performance or perceived performance win anymore. 

> However if you can convince me that
> a) the performance won't suffer much 
> b) people have asked for it
> c) and you know me by now :) have probes

Yes, I think we should definitely measure this closely if we flip the default here. But, given Marks comments in comment 7, what do you think now ? :)

Comment 10

[Barbara Bermes [:barbara] - NI please!]

I think Mark's comment (https://bugzilla.mozilla.org/show_bug.cgi?id=1219343#c7) almost convinced me from a user's perspective, I don't think I would necessarily want this to be default on.

Mark, compared to other defaults, would you say android.not_a_preference.restoreSession3 has been flipped more than the average time for a default value? Subtracting the times you or antlam flipped it.

> We should add a simple boolean histogram probe.
Could we please file a bug for this (I can if Mark hasn't already).

I create an Aha card for this?

Comment 11

[Karen Rudnitski [:kar]]

I'm trying to think about this not from my own personal usage, but thinking back to some user research interviews I've sat on (past and present).

In one case, the guy said he let his girlfriend use his phone / tablet to pass some time while she would hang out at his place. But that he would always clear history and ensure it was 'clean' before passing it to her. I can just imagine his reaction if we restored tabs by default, given he shared his hardware and liked that separation!

In another interview, a few things emerged. She liked going using top sites as a launch pad, and starting up the browser with that view made her feel 'happy to see that view' (that's the best way I can describe it, because she wasn't a proficient user but a general one, and she didn't feel comfortable let alone knowledgeable how to navigate the browser. Of course, that's a symptom likely of other things). 

She also mentioned in private browsing, she found it strange that tabs weren't automatically closed because anyone could pick up her device and navigate to her PB tabs and see what she was up to. That doesn't mean she wouldn't expect the same thing to happen with her public vs private tabs, but just another viewpoint to consider from a different but similar scenario. 

Finally, I think about tablet usage and how they're shared. It's likely that you wouldn't think of closing down all tabs after leaving the app, but you may not have thought about others seeing what you've been browsing when another family member picks it up. 

I think that (and myself included) where I'm very comfortable and confident with my phone, devices and browser, of *course* I have 'default to open previous tabs'. But I worry we're colouring it based on how we're using it in this case, and the general / average user may have a different expectation. I also think it's a difficult question to pose to an average user.

I don't think A/B testing is a good candidate here, but I like the idea of promoting this to users - whether during onboarding, an in-product tip that can show up (maybe on the home panel after the 3rd or 4th browser open just to inform the user), and/or use of the snippet to promote the option.

Comment 12

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Ah, thanks for the context Karen! Some thoughts below:

(In reply to Karen Rudnitski [:kar] from comment #11)
> I'm trying to think about this not from my own personal usage, but thinking
> back to some user research interviews I've sat on (past and present).
> 
> In one case, the guy said he let his girlfriend use his phone / tablet to
> pass some time while she would hang out at his place. But that he would
> always clear history and ensure it was 'clean' before passing it to her. I
> can just imagine his reaction if we restored tabs by default, given he
> shared his hardware and liked that separation!
> 
> In another interview, a few things emerged. She liked going using top sites
> as a launch pad, and starting up the browser with that view made her feel
> 'happy to see that view' (that's the best way I can describe it, because she
> wasn't a proficient user but a general one, and she didn't feel comfortable
> let alone knowledgeable how to navigate the browser. Of course, that's a
> symptom likely of other things). 
> 
> She also mentioned in private browsing, she found it strange that tabs
> weren't automatically closed because anyone could pick up her device and
> navigate to her PB tabs and see what she was up to. That doesn't mean she
> wouldn't expect the same thing to happen with her public vs private tabs,
> but just another viewpoint to consider from a different but similar
> scenario. 
> 
> Finally, I think about tablet usage and how they're shared. It's likely that
> you wouldn't think of closing down all tabs after leaving the app, but you
> may not have thought about others seeing what you've been browsing when
> another family member picks it up. 

Couple of questions here:

 - I wonder if this is more of a Tablet concern than a Mobile concern? 
 -- If so, are we prioritizing for the majority use case still? 
 - (Not sure when this research was done but) we've been focused a lot on the "Task Continuity" story, isn't this feature a large part of that? 
 - With the way other applications are behaving in this more and more "connected" World, are we still meeting user expectations? or do we feel "broken"?

> I think that (and myself included) where I'm very comfortable and confident
> with my phone, devices and browser, of *course* I have 'default to open
> previous tabs'. But I worry we're colouring it based on how we're using it
> in this case, and the general / average user may have a different
> expectation. I also think it's a difficult question to pose to an average
> user.

I'd agree. I think this is my main concern too. But I think user expectations may have shifted since when we last made this decision and I'm wondering if the value of this feature out-weighs the "costs" now.
 
> I don't think A/B testing is a good candidate here, but I like the idea of
> promoting this to users - whether during onboarding, an in-product tip that
> can show up (maybe on the home panel after the 3rd or 4th browser open just
> to inform the user), and/or use of the snippet to promote the option.

Maybe not a snippet... But a first run panel would be interesting. Though, I wonder if there's moar better info/features we could show in a slide.

Comment 13

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

bug 1238094 was filed and brought this up again – I'd hate for this to fall through the cracks again. Is there any action to take here here? Could we enable it by default and explain the behavior by onboarding (e.g. when tabs are restored for the first time, show UI to tell the user their tabs will be restored? Click here to disable this functionality?).

If we're not going to enable by default, should we investigate adding an onboarding item to prompt the user to enable it in the first place?

If it's interesting enough, we could get Gemma to add this as an investigation item in her research.

NI antlam so we have someone responsible for keeping this rolling.

Comment 14

[Aaron Train [:aaronmt]]

Actually thought this was a terrible bug having completely forgot about that preference and using an Android device today. From a quality perspective, this is a no brainer, we should always session restore and match expected behaviour.

Now why don't we restore private tabs: 1238397

Comment 15

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Michael Comella (:mcomella) from comment #13)
> bug 1238094 was filed and brought this up again – I'd hate for this to fall
> through the cracks again. Is there any action to take here here? Could we
> enable it by default and explain the behavior by onboarding (e.g. when tabs
> are restored for the first time, show UI to tell the user their tabs will be
> restored? Click here to disable this functionality?).
> 
> If we're not going to enable by default, should we investigate adding an
> onboarding item to prompt the user to enable it in the first place?
> 
> If it's interesting enough, we could get Gemma to add this as an
> investigation item in her research.
> 
> NI antlam so we have someone responsible for keeping this rolling.

This is currently in our Aha road map as a P2. 

Because we've preffed this off by default for so long, some users may need to change their habits. But in the long run, this will probably help us give most users (by default) a better experience WRT task continuity.

I feel like this is (enabled) has become somewhat expected behavior nowadays when we look at our competitors too. 

All in all, I think we should enable it by default. 

NI-ing barbara for context.

Comment 16

[Andrzej Hunt :ahunt]

I'm going to try and see how hard it is to do this just for new users for now - given that this seems like the most obvious setting, I doubt this is likely to cause any problems?

For existing users I'm still not sure where the expectations are - it would be interesting to have some form of onboarding screen to ask users what setting they want (for both existing and new users), or alternatively have a "second-run" screen shown along the lines of "would you like to restore your tabs from last time -> yes (always restore), no (never restore), yes (always ask)"?" - but I don't really think it's useful to invest much time in that.

Comment 17

[Barbara Bermes [:barbara] - NI please!]

Ok, here is an idea.

We do have numbers right now telling us that people flip this setting (without knowing which one though as far as I know), I'm also not sure if the probe histogram that Mark was talking about in https://bugzilla.mozilla.org/show_bug.cgi?id=1219343#c7 has been added.

How about we change it to the proposed setting, add a histogram probe to it and monitor its behavior. 
If we can't do what ahunt suggested, we might make people angry who have set this to off by default and now will see tabs on restore. Could we show these specific users that this is a feature we've changed and how they can revert back if they don't like it?

Changing something from default to new default requires a really good reason.

Comment 18

[Richard Newman [:rnewman]]

(In reply to Andrzej Hunt :ahunt from comment #16)
> I'm going to try and see how hard it is to do this just for new users for
> now - given that this seems like the most obvious setting, I doubt this is
> likely to cause any problems?

It should be mostly enough to flip the defaultValue entry in the pref for restoreSession3 (IIRC):

mobile/android/base/resources/xml/preferences_advanced.xml

and the fallback in GeckoApp:

1853:        return getSharedPreferences().getString(GeckoPreferences.PREFS_RESTORE_SESSION, "quit");

but if we never _set_ that pref to the default, the default will change for existing users unless we do more work.

Comment 19

[Karen Rudnitski [:kar]]

For existing users, I believe we shouldn't change their default. This could cause confusion, poor ratings, and like we're invading someone's preferences (even if they left it as default).

Why can't we just limit this change to new installs and leave existing users as-is? I don't feel like there's a real problem for existing users (ie I'm not sensing a lot of negative user feedback or queries related to this pref that would tell me that if we need to 'solve' a problem for existing users)

Comment 20

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Karen Rudnitski [:kar] from comment #19)
> For existing users, I believe we shouldn't change their default. This could
> cause confusion, poor ratings, and like we're invading someone's preferences
> (even if they left it as default).

Completely agree.

> Why can't we just limit this change to new installs and leave existing users
> as-is? I don't feel like there's a real problem for existing users (ie I'm
> not sensing a lot of negative user feedback or queries related to this pref
> that would tell me that if we need to 'solve' a problem for existing users)

Agree too.

Comment 21

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Picking up discussion about this here this week. Since, I have been looking at the Recent Tabs panel, this pref seems to affect it. 

I think Chenxia also pointed out a bug in this feature?

Comment 22

[Richard Newman [:rnewman]]

(In reply to Karen Rudnitski [:kar] from comment #19)

> Why can't we just limit this change to new installs and leave existing users
> as-is?

See comment 18. In short: it depends how you define "new user". If you define it as "a user who has never deliberately or inadvertently set that pref", then sure :)

Comment 23

[Richard Newman [:rnewman]]

Here's a counter proposal: this pref doesn't make sense.

Try it:

* Set to "Never restore"
* Background the app. Do something else.
* Open the app.

Your tabs are still there! But if you went off and did something really memory hungry, maybe they'd go away. So.

What "never restore" really means is "_sometimes_ randomly throw away my open tabs". The user doesn't understand that this is linked to the Android lifecycle.


So I propose removing this pref altogether, and always restore tabs.

If we think it's valuable, we can _add_ an option alongside "clear history on exit" to close tabs. That will add a Quit menu item, which gives a clear user signal to hang on to.

Chenxia, Margaret, and Anthony seem to agree with this.

Comment 24

[:Margaret Leibovic]

I agree with this proposal.

A nice side benefit of this is that we can remove "Tabs from last time" from the recent tabs panel, since there will be no such thing as "Tabs from last time". This will make migrating the recent tabs panel into the history panel simpler.

Comment 25

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Richard Newman [:rnewman] from comment #23)
> So I propose removing this pref altogether, and always restore tabs.
> 
> If we think it's valuable, we can _add_ an option alongside "clear history
> on exit" to close tabs. That will add a Quit menu item, which gives a clear
> user signal to hang on to.
> 
> Chenxia, Margaret, and Anthony seem to agree with this.

I don't think we even need to add an option here. This seems like a separate problem/conversation altogether.

Comment 26

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

(In reply to :Margaret Leibovic from comment #24)
> I agree with this proposal.
> 
> A nice side benefit of this is that we can remove "Tabs from last time" from
> the recent tabs panel, since there will be no such thing as "Tabs from last
> time". This will make migrating the recent tabs panel into the history panel
> simpler.

Seems reasonable.

Comment 27

[:Margaret Leibovic]

I want to do this. Let's try to get this done in 48.

It's currently a P2 in Aha, but we can move this into a target column:
https://mozilla.aha.io/features/FENN-359

Comment 28

[:Margaret Leibovic]

We're going to discuss this in the funnel meeting on Monday.

Comment 29

[Barbara Bermes [:barbara] - NI please!]

Agreed in funnel to for now just swap the default from off to on.

Comment 30

[Andrzej Hunt :ahunt]

Attachment: MozReview Request: Bug 1219343 - Enable "Always restore tabs" by default r?margaret

Note, the effect of this change varies as follows:

(A) New users:
(B) Existing users who have never opened Settings->Advanced:
- Tabs will restore by default

(D) Existing users who have explicitly set the preference to disabled:
(D) Existing users who visited Settings->Advanced, without explicitly opening this preference:
- Tabs will not restore by default
(The preference already has a value set, hence the default has no effect)

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

Comment 31

[:Margaret Leibovic]

(In reply to Andrzej Hunt :ahunt from comment #30)
> Created attachment 8734013 [details]
> MozReview Request: Bug 1219343 - Enable "Always restore tabs" by default
> r?margaret
> 
> Note, the effect of this change varies as follows:
> 
> (A) New users:
> (B) Existing users who have never opened Settings->Advanced:
> - Tabs will restore by default

Great, this sounds right.

> (D) Existing users who have explicitly set the preference to disabled:

Oh, nice. This is different (read: better) than if this was implemented with a gecko pref.

> (D) Existing users who visited Settings->Advanced, without explicitly
> opening this preference:
> - Tabs will not restore by default

Hm, this is a case where ideally I think we would switch this. But I'm not concerned enough about this edge case to add migration logic.

Comment 32

[:Margaret Leibovic]

Comment on attachment 8734013 [details]
MozReview Request: Bug 1219343 - Enable "Always restore tabs" by default r?margaret

https://reviewboard.mozilla.org/r/42059/#review38525

Comment 33

[Andrzej Hunt :ahunt]

https://hg.mozilla.org/integration/fx-team/rev/147628d074c876e6424deda66aa0128209f50486
Bug 1219343 - Enable "Always restore tabs" by default r=margaret

Comment 34

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/147628d074c8

Comment 35

[Flaviu Cos]

The behavior of this feature is confusing for users;

I used the following scenario:

Install fennec from scratch;
Open a few pages in different tabs;
Restart fennec;
  The tabs are restored;
Go to Settings - Advanced - Restore Tabs;
  The default option is "Don't restore after quitting Nighlty";
Restart fennec;
Tabs are no longer restored.

As a new user having my tabs restored as default only until entering settings is a bit confusing.

Comment 36

[Sebastian Kaspari (:sebastian; :pocmo)]

We didn't update the default for the preference screen:
https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/resources/xml/preferences_advanced.xml#30

Comment 37

[:Margaret Leibovic]

(In reply to Sebastian Kaspari (:sebastian) from comment #36)
> We didn't update the default for the preference screen:
> https://dxr.mozilla.org/mozilla-central/source/mobile/android/base/resources/
> xml/preferences_advanced.xml#30

Doh! Good catch. ahunt, can you file a follow-up bug and write a patch for that?

Comment 38

[Jan Henning [:JanH]]

(In reply to :Margaret Leibovic from comment #24)
> I agree with this proposal.
> 
> A nice side benefit of this is that we can remove "Tabs from last time" from
> the recent tabs panel, since there will be no such thing as "Tabs from last
> time". This will make migrating the recent tabs panel into the history panel
> simpler.

I can see one possible remaining use case: If we'd add an option in the crash reporter to optionally *not* restore the previous tabs (to provide an escape hatch from a crash loop if a certain tab is reliably crashing Firefox right on startup), it would be nice if the previous session could nevertheless be surfaced somehow in order for the user to be able to manually restore tabs as wanted.

Comment 39

[Flaviu Cos]

Verified as fixed in build 48.0a1 2016-04-11;
Device: Nexus 5 (Android 6.0.1).

Comment 40

[Andrzej Hunt :ahunt]

Clearning overdue NI, it's already fixed in Bug 1262444 : ) !

Comment 41

[Sorina Florean [:sflorean]]

Hi all, I will take this feature as a QA. Here is the Test plan based on which the testing is made: 
https://wiki.mozilla.org/QA/Fennec/Default_to_%22Always_restore_for_Tabs%22_settings_pref