1798086 - "Never remember history" (permanent private browsing) - unlike what the popup suggests, Firefox does not restore tabs when restarting for a software update

Status: NEW

(Firefox :: Session Restore, defect, P2)

Description

[funreal]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:106.0) Gecko/20100101 Firefox/106.0

Steps to reproduce:

I'm using the browser with 'never remember history'.

I had many important tabs open at which I suddenly got a pop-up message at the upper right corner telling that a new software update is available and all tabs will be restored after performing the update, so I clicked it.

Actual results:

Firefox did not restore my tabs after restart and I lost information.

Expected results:

At the very least detect that the user is running with 'never remember history' and adjust the update pop-up message to tell the user that current tabs will not restore after update.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Toolkit::Application Update' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Robin Steuber (she/her) [:bytesized]]

My understanding was that session restore was actually supposed to work in cases like this so I'm redirecting to the Session Restore component in order to investigate what I think is a bug in session restore.

If I am incorrect and this is the expected behavior, we probably should change the UI. In that case, please redirect this back to Application Update.

Comment 3

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

I managed to reproduce this issue on:

• Firefox 106.0.3(updated from a previous build on the "release" channel);
• Nightly 108.a1( updated from a previous build on the "nightly" channel);
• Firefox 107.0b8( updated from a previous build on the "beta" channel);

Tested and reproduced on:

• Ubuntu 22;
• macOS 12;
• Windows 10;

Setting as NEW so that the developers can have a look.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:dao, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Dão Gottwald [:dao]]

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #2)

My understanding was that session restore was actually supposed to work in cases like this so I'm redirecting to the Session Restore component in order to investigate what I think is a bug in session restore.

Are you suggesting there's a regression? If so a regression range would be helpful.

I suspect this isn't a regression, but also not a bug in session restore. "Never remember history" is a sanitizer pref, so if we want to make an exception for restarts that probably needs to be handled somewhere in Sanitizer.jsm similarly to how session restore handles sessionstore.resume_session_once.

Searchfox tells me Sanitizer.jsm is handled in Firefox::Settings UI, so moving this there for now for further investigation.

Comment 6

[Robin Steuber (she/her) [:bytesized]]

(In reply to Dão Gottwald [::dao] from comment #5)

Are you suggesting there's a regression?

No, but it was my understanding that restarting to apply updates is meant to restore your session regardless of how your preferences are set.

Comment 7

[funreal]

No, but it was my understanding that restarting to apply updates is meant to restore your session regardless of how your preferences are set.

Makes sense.

I would have delayed the update had I known session(s) are not restored.

Comment 8

[Ciprian Georgiu, Desktop QA]

I don't think we can find out or look for a regression range since this implies updating Firefox builds, as comment 3 and comment 1 suggests. I'm going to remove the regressionwindow-wanted keyboard.

Comment 9

[:Gijs (he/him)]

"Never remember history" is different from the sanitizer (clearing history on shutdown), but also, the metadata for Sanitizer.sys.mjs should not point to settings UI - I filed bug 1801838. I've also updated the summary to be more descriptive so it's easier to find this bug. I think this should be in either session store or private browsing.

It looks to me like not saving history even for update restarts was a deliberate change in bug 1433523, 5 years ago - but perhaps I'm misreading the patch or there was some other place in the code that was supposed to deal with the update case that got removed. It's worth noting that the code that sets resume_session_once in BrowserGlue only runs if passed aForce, and the only caller for that is a session-save observer notification, which I can only see 1 instance of - in Linux-only code that looks like it's been perma-disabled (no coverage) for the past 5+ years anyway. So I'm pretty lost. More generally sessions haven't been saved in permanent private browsing in general (expected, I think) in bug 944557, so for much longer still.

Arthur, Josh and Mike from bug 1433523 are all no longer around. Tom, bit of a long shot but do you have context for what that change was supposed to achieve, given it was originally a Tor browser patch, and if the update restart was part of it?

We can update the messaging in the popup but honestly I think it'd be a better user experience if instead we preserved the session for the case of permanent private browsing - it'd help people update more quickly which is important for their security and privacy too...

Comment 10

[:Gijs (he/him)]

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

I think this should be in either session store or private browsing.

Or, I suppose, in an app update component if we decide to "just" change the messaging for permanent private browsing.

Comment 11

[Tom Ritter [:tjr] (OOTO until 7/21)]

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

Arthur, Josh and Mike from bug 1433523 are all no longer around. Tom, bit of a long shot but do you have context for what that change was supposed to achieve, given it was originally a Tor browser patch, and if the update restart was part of it?

I don't have any context. My guess is that there were two things happening:

1. Session Restore was not saving anything to be restored when an update occurred
2. After an update occurred in Permanent Private Browsing mode, Session Restore went looking for something to restore.

The combination of #2 and #1 meant that there was nothing to be found, nothing was restored, and about:tor was not shown (when it was expected to be.) The change made in the patch was to nullify #2: in Permanent Private Browsing mode do not go looking for something to restore. (i.e. make isAutomaticRestoreEnabled return false) This made the browser take a normal-ish startup path and about:tor was shown as expected.

If that guess is right, it means that #1 (what this bug is about) was already happening.

Now I could be wrong about that, #1 is based on the fact that in the tor browser ticket no one is talking about "My open tabs were also restored". Maybe they didn't test that?

I'd suggest just commenting out the patch added in Bug 1433523 and seeing if it behaves the way we want. If so, we can talk to Tor about not regressing their original problem and/or not having this behavior in Tor Browser.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1433523

Comment 13

[Sarah Clements [:sclements] | PTO until July 14th]

Paul, since you've been doing work to delete certain data for private windows per bug 1846495 and bug 1861215 I want to get some input on this to see if it'd overlap or interfere with work you're doing (if we changed the behavior to fix the lack of restoring a session for updates in permanent private browsing mode vs changing the messaging). I'm also not entirely sure if permanent private browsing mode is essentially the same as Private browsing mode/private windows, so hoping you could also shed light on the distinction.

Comment 14

[Emma Zühlcke [:emz]]

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

Paul, since you've been doing work to delete certain data for private windows per bug 1846495 and bug 1861215 I want to get some input on this to see if it'd overlap or interfere with work you're doing (if we changed the behavior to fix the lack of restoring a session for updates in permanent private browsing mode vs changing the messaging).

This shouldn't overlap or interfere with the reset feature we've added in Bug 1846495.

Is it possible to restore session store data after a restart without writing the session store data to disk? We don't usually persist anything to disk for private browsing mode. I'm not sure if permanent private browsing mode behaves differently though.

I'm also not entirely sure if permanent private browsing mode is essentially the same as Private browsing mode/private windows, so hoping you could also shed light on the distinction.

Permanent private browsing mode means all windows are private browsing windows. So it's essentially like private browsing mode, except for some UI tweaks.