1820660 - Persist a record of recently closed tabs from all non-private browser windows

Status: RESOLVED FIXED

(Firefox :: Session Restore, enhancement)

Description

[Sam Foster [:sfoster] (he/him)]

• After a user ends a session/closes the last window, the closed tabs from all previous windows will persist for 24 hours 7 days.
• Don't include private windows

Currently, "recently" is defined to mean recently in this session. Users frequently expect it to mean "not long ago", regardless of whether the browser has been re-started and a new session created in that time.

This comes from a firefox-view feature request, but as I understand it would need to be implemented mostly within the code covered by the Session Restore component. The firefox view views into the recently closed tabs data should pretty much "just work" at that point.

Comment 1

[Sarah Clements [:sclements]]

This requirement was changed to "persist for 7 days" per a chat today with Katie, Eric and Emanuella. Any questions, :klower is the UX/content point person.

Comment 2

[klower]

Proactively adding the 'why': The 7 days parameter accommodates non-daily, occasional users. For daily, or more active users, the list would likely be capped first by the maximum amount (25) than by the time (7 day) restriction.

For clarity: Tabs closed more than 7 days ago should be cleared from the list - even if the list has fewer than 25 items. Why? To keep the list having some sense of recency.

Comment 3

[Sarah Clements [:sclements]]

Katie, how should 'restore previous session' work with this change? Currently you can restore a session if you quit the browser or it has crashed unexpectedly. Should this option be removed entirely except for cases where the browser has crashed (and then what would be restored)?

Edit: Actually I think I conflated the difference between restoring the last session with regards to last open tabs vs persisting recently closed tabs and windows, so nevermind. :)

Comment 4

[Sarah Clements [:sclements]]

There's a bit of a paradigm shift with the ask from UX about this feature: ideally we'd persist the recently closed tabs for 7 days regardless of whether the user has restored the last session or has that setting enabled in about:preferences (it would still behave the same if a user cleared history). I understand there might be some push back with this, and it'd be good to hear some perspectives about why this may or may not be a good change.

For some context, epang told me that during a small research study where users were shown a prototype of recently closed tabs that persisted even if they accidentally closed the window/browser. I think this is an attempt to make sure something is always available, since currently if a user closes a tab on the last open window and quit, they can't restore that session (I don't know if this was by design or not but they can reopen the recently closed window at least).

Dao, since you're the triage owner do you have any opinion or POV you'd like considered (or is there another engineer with historical knowledge you think should weigh in)?

Comment 5

[:Gijs (he/him)]

(In reply to Sarah Clements [:sclements] from comment #4)

There's a bit of a paradigm shift with the ask from UX about this feature: ideally we'd persist the recently closed tabs for 7 days regardless of whether the user has restored the last session or has that setting enabled in about:preferences (it would still behave the same if a user cleared history). I understand there might be some push back with this, and it'd be good to hear some perspectives about why this may or may not be a good change.

I think this is reasonable, although we should define how this interacts with "clear recent history" and/or "clear history when Firefox closes". There are extant bugs about this interaction being unclear, cf. bug 1796682. "History" is kind of a fuzzy concept in this context - from an engineering PoV the tabs are distinct from "history" as a bit of info in places, but for users that may not be the case, etc.

Otherwise, if I understand correctly:

• this behaviour is well-defined for people who have automatic session restore enabled, and more or less what we already do, but we will now expire recently closed tabs after 7 days (may be useful to edit comment 0 to avoid confusion, fwiw).
• for people who don't have automatic session restore enabled, we will persist the closed tabs. This is similar to what we do for pinned tabs today (which will restore even if you don't enable automatic session restore).

The open question for me is: in the case where people don't have automatic session restore enabled, what happens to tabs/windows that are open when the user closes the browser? Do they get added to the collection of "recently closed tabs"? It would be kind of odd if those tabs "disappear" (aren't accessible after the restart except through "restore last session") but the recently closed tabs stay available in "recently closed tabs". Part of me thinks it would be more straightforward if we treated them as "closed tabs", too, but of course making that work with "restore last session" is not straightforward. What's the thinking around this? I can't quite tell from the comments here...

Comment 6

[Sarah Clements [:sclements]]

(In reply to :Gijs (he/him) from comment #5)

(In reply to Sarah Clements [:sclements] from comment #4)

There's a bit of a paradigm shift with the ask from UX about this feature: ideally we'd persist the recently closed tabs for 7 days regardless of whether the user has restored the last session or has that setting enabled in about:preferences (it would still behave the same if a user cleared history). I understand there might be some push back with this, and it'd be good to hear some perspectives about why this may or may not be a good change.

I think this is reasonable, although we should define how this interacts with "clear recent history" and/or "clear history when Firefox closes". There are extant bugs about this interaction being unclear, cf. bug 1796682. "History" is kind of a fuzzy concept in this context - from an engineering PoV the tabs are distinct from "history" as a bit of info in places, but for users that may not be the case, etc.

Good point around clearing history. epang said recently closed tabs should clear when a user clears history so we should prioritize those bugs as well so its consistently applied.

Otherwise, if I understand correctly:

• this behaviour is well-defined for people who have automatic session restore enabled, and more or less what we already do, but we will now expire recently closed tabs after 7 days (may be useful to edit comment 0 to avoid confusion, fwiw).
• for people who don't have automatic session restore enabled, we will persist the closed tabs. This is similar to what we do for pinned tabs today (which will restore even if you don't enable automatic session restore).

The open question for me is: in the case where people don't have automatic session restore enabled, what happens to tabs/windows that are open when the user closes the browser? Do they get added to the collection of "recently closed tabs"? It would be kind of odd if those tabs "disappear" (aren't accessible after the restart except through "restore last session") but the recently closed tabs stay available in "recently closed tabs". Part of me thinks it would be more straightforward if we treated them as "closed tabs", too, but of course making that work with "restore last session" is not straightforward. What's the thinking around this? I can't quite tell from the comments here...

Good point, let me check in with Eric on that. I'm wondering though, if we preserve those opens tabs but add them as recently closed tabs, what makes 'restore last session' different (aside from those last open tabs opening up again instead of being added to recently closed)?

Comment 7

[:Gijs (he/him)]

(In reply to Sarah Clements [:sclements] from comment #6)

(In reply to :Gijs (he/him) from comment #5)

Otherwise, if I understand correctly:

• this behaviour is well-defined for people who have automatic session restore enabled, and more or less what we already do, but we will now expire recently closed tabs after 7 days (may be useful to edit comment 0 to avoid confusion, fwiw).
• for people who don't have automatic session restore enabled, we will persist the closed tabs. This is similar to what we do for pinned tabs today (which will restore even if you don't enable automatic session restore).

The open question for me is: in the case where people don't have automatic session restore enabled, what happens to tabs/windows that are open when the user closes the browser? Do they get added to the collection of "recently closed tabs"? It would be kind of odd if those tabs "disappear" (aren't accessible after the restart except through "restore last session") but the recently closed tabs stay available in "recently closed tabs". Part of me thinks it would be more straightforward if we treated them as "closed tabs", too, but of course making that work with "restore last session" is not straightforward. What's the thinking around this? I can't quite tell from the comments here...

Good point, let me check in with Eric on that. I'm wondering though, if we preserve those opens tabs but add them as recently closed tabs, what makes 'restore last session' different (aside from those last open tabs opening up again instead of being added to recently closed)?

If we both keep the tabs in the "last session" info and add them to recently closed tabs in the manual session restore case, the difference is as follows: automatically restoring the session would open the tabs immediately; In the manual restore case, I think treating the not-restored tabs as "closed" would then allow reopening them with "undo close tab".

If we wanted to allow "restore previous session" at the same time, then we'd have to ensure that there's no duplication, ie if the user restores the session the tabs get removed from "recently closed tabs", and vice versa, if instead the user starts by reopening closed tabs, they get removed from the "previous session" state so that doing "restore previous session" later doesn't then reopen those tabs a second time.

Comment 8

[Eric Pang [:epang] UX]

(In reply to Sarah Clements [:sclements] from comment #6)

(In reply to :Gijs (he/him) from comment #5)

(In reply to Sarah Clements [:sclements] from comment #4)

There's a bit of a paradigm shift with the ask from UX about this feature: ideally we'd persist the recently closed tabs for 7 days regardless of whether the user has restored the last session or has that setting enabled in about:preferences (it would still behave the same if a user cleared history). I understand there might be some push back with this, and it'd be good to hear some perspectives about why this may or may not be a good change.

I think this is reasonable, although we should define how this interacts with "clear recent history" and/or "clear history when Firefox closes". There are extant bugs about this interaction being unclear, cf. bug 1796682. "History" is kind of a fuzzy concept in this context - from an engineering PoV the tabs are distinct from "history" as a bit of info in places, but for users that may not be the case, etc.

Good point around clearing history. epang said recently closed tabs should clear when a user clears history so we should prioritize those bugs as well so its consistently applied.

Otherwise, if I understand correctly:

• this behaviour is well-defined for people who have automatic session restore enabled, and more or less what we already do, but we will now expire recently closed tabs after 7 days (may be useful to edit comment 0 to avoid confusion, fwiw).
• for people who don't have automatic session restore enabled, we will persist the closed tabs. This is similar to what we do for pinned tabs today (which will restore even if you don't enable automatic session restore).

The open question for me is: in the case where people don't have automatic session restore enabled, what happens to tabs/windows that are open when the user closes the browser? Do they get added to the collection of "recently closed tabs"? It would be kind of odd if those tabs "disappear" (aren't accessible after the restart except through "restore last session") but the recently closed tabs stay available in "recently closed tabs". Part of me thinks it would be more straightforward if we treated them as "closed tabs", too, but of course making that work with "restore last session" is not straightforward. What's the thinking around this? I can't quite tell from the comments here...

Good point, let me check in with Eric on that. I'm wondering though, if we preserve those opens tabs but add them as recently closed tabs, what makes 'restore last session' different (aside from those last open tabs opening up again instead of being added to recently closed)?

Thanks for the flag Sarah.

We should add tabs that were left open when the browser is closed to the list of recently closed tabs like Gijs mentioned.

Scenarios:

1. If the user doesn't restore the session the tabs get added to the recently closed tabs list
2. If the user restores we open the tabs back up as open tabs and don't add them (or remove them, if already added) to the recently closed tabs list. (This follows the behaviour of clicking and restoring an list item from the recently closed list).

Comment 9

[Sarah Clements [:sclements]]

Attachment: WIP: Bug 1820660 - Persist recently closed tabs between sessions for 7 days

Comment 10

[Sarah Clements [:sclements]]

Attachment: Bug 1820660 - Persist recently closed tabs between sessions r=dao

• For cases where a user does not have automatic session restore enabled, recently closed
  tabs will persist between sessions and previously open tabs will be added to the recently closed tabs
  list; upon manual session restore, the previously open tabs will reopen and be removed from the closed tabs list

• Add marionette test and fix test bustages due to these changes.

Comment 11

[Sarah Clements [:sclements]]

Attachment: Bug 1820660 - Recently closed tabs persist between sessions for 7 days r=dao,sfoster

• Recently closed tabs will no longer be truncated to whatever max_undo_tabs prefs is set to, instead closed tabs will
  be filtered for recency (max 7 days old), during SessionStore.initSession.

• Add marionette tests for the above two scenarios, and fix test bustages due to these changes.

Comment 12

[Walter K.]

(In reply to Sarah Clements [:sclements] from comment #11)

Created attachment 9335257 [details]
Bug 1820660 - Recently closed tabs persist between sessions for 7 days r=Gijs,dao,sfoster

• Recently closed tabs will no longer be truncated to whatever max_undo_tabs prefs is set to, instead closed tabs will
  be filtered for recency (max 7 days old), during SessionStore.initSession.

• Add marionette tests for the above two scenarios, and fix test bustages due to these changes.

Stop. This is actually breaking Recently Closed Tabs. While fixing lost cross-session tab history is needed, arbitrary trimming tab history after 7 days is illogical and random. Within content of History, "recent" means "last".

This will lead to new bugs being filled by people not knowing why items from the list are getting inexplicably lost. Keep sessionstore.max_tabs_undo pref, leave logical and consistent Recently Closed Tabs be. If wanted, this new tabs history feature you are creating should be explicitly called Tabs from the last 7 days or similar, not Recently Closed Tabs. Why me going on vacation for a week should lead to loosing all recent tabs?

If Firefox View wants to display tabs from the last 7 days, it should be a separate feature there.

Comment 13

[Sarah Clements [:sclements]]

(In reply to Walter K. from comment #12)

(In reply to Sarah Clements [:sclements] from comment #11)

Created attachment 9335257 [details]
Bug 1820660 - Recently closed tabs persist between sessions for 7 days r=Gijs,dao,sfoster

• Recently closed tabs will no longer be truncated to whatever max_undo_tabs prefs is set to, instead closed tabs will
  be filtered for recency (max 7 days old), during SessionStore.initSession.

• Add marionette tests for the above two scenarios, and fix test bustages due to these changes.

Stop. This is actually breaking Recently Closed Tabs. While fixing lost cross-session tab history is needed, arbitrary trimming tab history after 7 days is illogical and random. Within content of History, "recent" means "last".

This will lead to new bugs being filled by people not knowing why items from the list are getting inexplicably lost. Keep sessionstore.max_tabs_undo pref, leave logical and consistent Recently Closed Tabs be. If wanted, this new tabs history feature you are creating should be explicitly called Tabs from the last 7 days or similar, not Recently Closed Tabs. Why me going on vacation for a week should lead to loosing all recent tabs?

If Firefox View wants to display tabs from the last 7 days, it should be a separate feature there.

First of all, your comment is quite rude - I understand you have concerns about this change but please remember you are speaking to people who are dedicated to working on this full time and thought and planning has gone into this. See comment 2 for why this change regarding last 7 days is being implemented, however I'm sure our UX team will take your feedback into account. Additionally, this initial implementation puts the 7 days value behind a pref - this was mostly for testing-related reasons but it obviously then gives users some level of customization.

Currently recently closed tabs is saved in SessionStore based on whatever the max_tabs_undo pref is set to - the default being 25 tabs - and so this change also accommodates plans to show more recently closed tabs in future features than just the last 25.

Comment 14

[Sarah Clements [:sclements]]

Katie, Eric, I wanted to follow up on a particular aspect of the persisting tabs for 7 days change. Per this spec for recently closed tabs where we 'show all recently closed tabs', the annotations indicate that once clicked, all tabs from the past 7 days should be displayed.

Now, the potential issue with this is that a very small percentage of users could generate close to 450 closed tabs within a 7 day period, per this query of the closed tab button probe (so caveat being that this query is only for that probe, and not for closing a tab via context menu - although those numbers look quite small - or via different options to close multiple tabs at once).

My understanding is that you all didn't want to limit the number of tabs outside of the 7-day limit across the browser, not just for Firefox View. The current behavior is to limit the closed tabs that are stored to 25, which is based on the max_tabs_undo pref (and something a user could change if they wanted to).

Because of that, we should probably continue to keep a cap on the number of closed tabs we store between sessions. If we changed the default value of what we limit the recently closed tabs to 100 this would still show significantly more recently closed tabs than we currently do and would cover about a weeks worth for a majority of users.

Additionally, if we did change the number of tabs we save, should we add a separate limitation (say 25, to preserve current behavior) to the other surfaces/menus that show recently closed tabs?

From an engineering perspective though, changing that particular pref also affects how many tabs can be reopened at a time... so if a user selects 100 tabs and closes them, they'll be able to reopen 100 tabs at a time as well so it might be worth decoupling that behavior.

Gijs, Dao, Sam - please chime in if you think this number is too high.

Comment 15

[Sam Foster [:sfoster] (he/him)]

Thanks for digging into the data to get that 450 number - that's useful to have. Yeah, because we currently limit the number of closed tabs we keep to 25 via the sessionstore.max_tabs_undo pref, we don't need to limit the number of menu items we show, or put any cap on the number of tabs re-opened from the "Reopen all tabs" menu item. It feels like we may need 2 numbers: how many we'll save (could be 25 - Infinity), and how many we'll show. Of course the problem with closed tabs vs say bookmarks or history is that there's not yet anywhere to direct users to see see the whole collection if we needed to truncate it.

As just one data point, I bumped up my max_tabs_undo earlier this week so that as of right now I have 3 browser windows open, with a total of 89 closed tabs[1]. On this laptop, the history menu can show about 30 items before I have to start scrolling.

I'm pretty sure there's diminishing returns with closed tab data. Do you really need to be able to restore all of the 450 tabs you recently closed? Or is it enough to have entries in your history so you can open a new tab at the same URL. Remember with closed tabs we keep the all the history for that tab, your scroll position and a bunch of other state in addition to the actual URL the tab had loaded at the time it was closed. Its most useful as a recovery/undo mechanism.

1. You can find how many closed tabs you have by running this snippet in the browser console:
   BrowserWindowTracker.orderedWindows.map(win => SessionStore.getClosedTabCount(win)).reduce((sum, count) => sum += count, 0)

Comment 16

[Eric Pang [:epang] UX]

Let's keep the cap at 25. I prefer to keep the recently closed tabs, recent. I'll remove the "show more..." in the spec. I added it in based on discussions during the hand off, but thinking about it more now, I don't think it's needed since if users are going further back they can look into their history. Thanks for flagging.

(In reply to Sarah Clements [:sclements] from comment #14)

Katie, Eric, I wanted to follow up on a particular aspect of the persisting tabs for 7 days change. Per this spec for recently closed tabs where we 'show all recently closed tabs', the annotations indicate that once clicked, all tabs from the past 7 days should be displayed.

Now, the potential issue with this is that a very small percentage of users could generate close to 450 closed tabs within a 7 day period, per this query of the closed tab button probe (so caveat being that this query is only for that probe, and not for closing a tab via context menu - although those numbers look quite small - or via different options to close multiple tabs at once).

My understanding is that you all didn't want to limit the number of tabs outside of the 7-day limit across the browser, not just for Firefox View. The current behavior is to limit the closed tabs that are stored to 25, which is based on the max_tabs_undo pref (and something a user could change if they wanted to).

Because of that, we should probably continue to keep a cap on the number of closed tabs we store between sessions. If we changed the default value of what we limit the recently closed tabs to 100 this would still show significantly more recently closed tabs than we currently do and would cover about a weeks worth for a majority of users.

Additionally, if we did change the number of tabs we save, should we add a separate limitation (say 25, to preserve current behavior) to the other surfaces/menus that show recently closed tabs?

From an engineering perspective though, changing that particular pref also affects how many tabs can be reopened at a time... so if a user selects 100 tabs and closes them, they'll be able to reopen 100 tabs at a time as well so it might be worth decoupling that behavior.

Gijs, Dao, Sam - please chime in if you think this number is too high.

Comment 17

[Sarah Clements [:sclements]]

(In reply to Eric Pang [:epang] UX from comment #16)

Let's keep the cap at 25. I prefer to keep the recently closed tabs, recent. I'll remove the "show more..." in the spec. I added it in based on discussions during the hand off, but thinking about it more now, I don't think it's needed since if users are going further back they can look into their history. Thanks for flagging.

Thanks for clarifying Eric. I'm wondering if we should also change the 7 day period to 8 days or a little longer? Perhaps this is something we can experiement with, and err on the side of being conservative and not introducing too many major changes at once.

Comment 18

[Eric Pang [:epang] UX]

(In reply to Sarah Clements [:sclements] from comment #17)

(In reply to Eric Pang [:epang] UX from comment #16)

Let's keep the cap at 25. I prefer to keep the recently closed tabs, recent. I'll remove the "show more..." in the spec. I added it in based on discussions during the hand off, but thinking about it more now, I don't think it's needed since if users are going further back they can look into their history. Thanks for flagging.

Thanks for clarifying Eric. I'm wondering if we should also change the 7 day period to 8 days or a little longer? Perhaps this is something we can experiement with, and err on the side of being conservative and not introducing too many major changes at once.

I've always thought 7 days felt a bit shot of a timeframe to be honest. Why don't we update to 14 days. After 2 weeks it's much more likely that the user will no longer need to reopen the tab anymore. We should closely monitor the reactions we get and tweak as needed. If users are surprised they are disappearing we can always take away the time constraint and just have the cap of the 25 most recently closed tabs.

Comment 19

[:Gijs (he/him)]

(In reply to Eric Pang [:epang] UX from comment #18)

(In reply to Sarah Clements [:sclements] from comment #17)

(In reply to Eric Pang [:epang] UX from comment #16)

Let's keep the cap at 25. I prefer to keep the recently closed tabs, recent. I'll remove the "show more..." in the spec. I added it in based on discussions during the hand off, but thinking about it more now, I don't think it's needed since if users are going further back they can look into their history. Thanks for flagging.

Thanks for clarifying Eric. I'm wondering if we should also change the 7 day period to 8 days or a little longer? Perhaps this is something we can experiement with, and err on the side of being conservative and not introducing too many major changes at once.

I've always thought 7 days felt a bit shot of a timeframe to be honest. Why don't we update to 14 days. After 2 weeks it's much more likely that the user will no longer need to reopen the tab anymore. We should closely monitor the reactions we get and tweak as needed. If users are surprised they are disappearing we can always take away the time constraint and just have the cap of the 25 most recently closed tabs.

I hesitate to suggest more adjustments, but are we happy that keeping a cap of 25 makes sense given that previously, it's 25 tabs per window and after these patches it'd be 25 total. So if I close a window with 10 tabs, do the remaining window's closed tabs get restricted down to the last 15 (as the just-closed 10 from the other window are more recently closed), and are we sure that's OK?

Comment 20

[Eric Pang [:epang] UX]

(In reply to :Gijs (he/him) from comment #19)

(In reply to Eric Pang [:epang] UX from comment #18)

(In reply to Sarah Clements [:sclements] from comment #17)

(In reply to Eric Pang [:epang] UX from comment #16)

Let's keep the cap at 25. I prefer to keep the recently closed tabs, recent. I'll remove the "show more..." in the spec. I added it in based on discussions during the hand off, but thinking about it more now, I don't think it's needed since if users are going further back they can look into their history. Thanks for flagging.

Thanks for clarifying Eric. I'm wondering if we should also change the 7 day period to 8 days or a little longer? Perhaps this is something we can experiement with, and err on the side of being conservative and not introducing too many major changes at once.

I've always thought 7 days felt a bit shot of a timeframe to be honest. Why don't we update to 14 days. After 2 weeks it's much more likely that the user will no longer need to reopen the tab anymore. We should closely monitor the reactions we get and tweak as needed. If users are surprised they are disappearing we can always take away the time constraint and just have the cap of the 25 most recently closed tabs.

I hesitate to suggest more adjustments, but are we happy that keeping a cap of 25 makes sense given that previously, it's 25 tabs per window and after these patches it'd be 25 total. So if I close a window with 10 tabs, do the remaining window's closed tabs get restricted down to the last 15 (as the just-closed 10 from the other window are more recently closed), and are we sure that's OK?

Thanks Gijs, I appreciate the flag! I think it's okay since the 10 tabs that have been closed in the window now become the most recently closed tabs in all windows and pushes the list down, with all the windows showing the same list. In testing the use case that stood out the most for recently closed tabs is when a user accidentally closed a tab and wanted to get it back, so most of the time it should be close to the top of the list anyway.

There is one more change I wanted to propose that is related though. After speaking with Katie we decided to add a link to the bottom of the 25 items. "View more browsing history" - this link goes to the history page incase users want to go further back than what is shown in the 25 list items. I've updated the specs to reflect this. Is this something we can do?

Comment 21

[Sam Foster [:sfoster] (he/him)]

(In reply to Eric Pang [:epang] UX from comment #20)

There is one more change I wanted to propose that is related though. After speaking with Katie we decided to add a link to the bottom of the 25 items. "View more browsing history" - this link goes to the history page incase users want to go further back than what is shown in the 25 list items. I've updated the specs to reflect this. Is this something we can do?

Where would this link go? For the history -> recently closed tabs menus, there's already a "Reopen all tabs" item at the end of the menu. After that? Or are we just talking about the firefox view list. And by history page, you mean the history "page" of (the new) firefox view? We'll want a new bug for this and a spec I think so everyone has something to refer to. I can create the bug if you can create the spec :)

Comment 22

[Sarah Clements [:sclements]]

(In reply to Eric Pang [:epang] UX from comment #20)

There is one more change I wanted to propose that is related though. After speaking with Katie we decided to add a link to the bottom of the 25 items. "View more browsing history" - this link goes to the history page incase users want to go further back than what is shown in the 25 list items. I've updated the specs to reflect this. Is this something we can do?

I thought this had been discussed previously and discarded since it could be confusing to redirect users from recently closed tabs to browsing history? Regardless that is not specifically related to this recently closed tabs/session store work though, so lets take that conversation outside of this particular bug. I don't think we'd need a new bug for it though, presumably this would be at the bottom of the recently closed tabs view where previously there was a "show all recently closed tabs" link and it would just need an updated spec?

I do wonder as Gijs has about 25 tabs being too limited in the event users have closed tabs from multiple windows. I think it would make sense to bump the max_tabs_undo number a little bit.

Comment 23

[Eric Pang [:epang] UX]

(In reply to Sam Foster [:sfoster] (he/him) from comment #21)

(In reply to Eric Pang [:epang] UX from comment #20)

There is one more change I wanted to propose that is related though. After speaking with Katie we decided to add a link to the bottom of the 25 items. "View more browsing history" - this link goes to the history page incase users want to go further back than what is shown in the 25 list items. I've updated the specs to reflect this. Is this something we can do?

Where would this link go? For the history -> recently closed tabs menus, there's already a "Reopen all tabs" item at the end of the menu. After that? Or are we just talking about the firefox view list. And by history page, you mean the history "page" of (the new) firefox view? We'll want a new bug for this and a spec I think so everyone has something to refer to. I can create the bug if you can create the spec :)

Hey Sam, so this would be only for the firefox view list. The link will go to the new history page in View. I've updated the spec here: https://www.figma.com/file/wP9MY9KJn9xqPf140lTvTv/Fx-View-Specs-2023?type=design&node-id=2377-51572
Thanks Sam, sorry I wasn't very clear earlier.

Sarah, that's right, this will replace the "show all recently closed tabs" link we had previously. The idea is to point the user in a direction if they are having trouble finding what they are looking for regardless. The recommendation was from Katie since something similar was done for the empty state.

Comment 24

[Sarah Clements [:sclements]]

The more I think about the persisting for 7 or 14 days part of this bug the more I think we should postpone this change. This is not the kind of thing we can undo if we get it wrong (undo in the sense that, even if we reverted this code it will still have erased any of the 25 closed tabs older than that time period). I believe Sam has spoken to Luca Greco about this a bit but I'd also like to give the extensions team more time to weigh in on the implications of this change.

I'm going to recommend to James and Emanuella that we postpone this particular change for now, especially since there's already going to be quite substantial changes to recently closed tabs/session restore and this part isn't really important to the larger work being done IMO.

Comment 25

[Sarah Clements [:sclements]]

The filtering by time is being dropped after discussions with James and UX team.

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0e2af922ec2a
Persist recently closed tabs between sessions r=dao,sfoster,extension-reviewers,sessionstore-reviewers,robwu

Comment 27

[Cosmin Sabou [:CosminS]]

Backed out for causing webdriver failures on add_cookie/user_prompts.py

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&tochange=738f26e12fc8d08084ae1c79292799a1de744c9a&fromchange=0e2af922ec2aa5011ff5cdc73bda4582199f3279&searchStr=wd&selectedTaskRun=RPM8_-08RlOGR_O3cI6L6Q.0

Failures log:

• webdriver - https://treeherder.mozilla.org/logviewer?job_id=419091939&repo=autoland
• marionette - https://treeherder.mozilla.org/logviewer?job_id=419091889&repo=autoland / https://treeherder.mozilla.org/logviewer?job_id=419093342&repo=autoland

Backout link: https://hg.mozilla.org/integration/autoland/rev/738f26e12fc8d08084ae1c79292799a1de744c9a

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8737a1c1bc55
Persist recently closed tabs between sessions r=dao,sfoster,extension-reviewers,sessionstore-reviewers,robwu

Comment 29

[Sandor Molnar]

https://hg.mozilla.org/mozilla-central/rev/8737a1c1bc55

Comment 30

[Sarah Clements [:sclements]]

Release Note Request (optional, but appreciated) - for Nightly only please
[Why is this notable]: Recently closed tabs now persists between sessions in Nightly only (behind a pref, which will be removed at a later time), for user that don't have automatic session restore enabled.
[Affects Firefox for Android]: No
[Suggested wording]: Recently closed tabs now persists between sessions for users that don't have automatic session restore enabled. Manually restoring a previous session will continue to reopen any previously open tabs or windows.
[Links (documentation, blog post, etc)]: n/a

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Added to the Nightly relnotes.

Comment 32

[Dianna Smith [:diannaS]]

Added to Fx119 notes(https://www.mozilla.org/en-US/firefox/119.0beta/releasenotes/) as this was enabled by default by bug 1852094