1751366 - Disable tab unloading in private windows (Firefox update coupled with tabs unloading can cause loss of tabs in private browsing)

Status: RESOLVED FIXED

(Firefox :: Tabbed Browser, defect)

Description

[Clément Lefèvre]

Attachment: Screenshot from 2022-01-21 10-06-56.png

Since recently, tabs unload have been implemented in Firefox for not recently used tabs.
This is done in both normal windows and private browsing one.

Problem is, if Firefox is updated in the background, accidentally or not (for my par tit was through distribution's package manager, didn't noticed firefox was in the list of updates), it doesn't want to load tabs anymore (I also think this behavior is new, and that it used to be possible to use Firefox completely without restart and despite the update) because it result in what can be seen in the joined screenshot.

Problem comes when you have this behavior with private tab windows: tabs are unloaded and when it happens, address bar becomes empty resulting in the loss of tab's content.

Comment 2

[Clément Lefèvre]

::dao I reopen, I believe this is not a dupe.
The bug you duped onto is only about wording of the text. Mine is to describe a situation where, when this text is shown, user already lost their private tabs because they've been unloaded with this new feature (unloading unused tabs).

Comment 3

[Dão Gottwald [:dao]]

So this is actually not duplicate of bug 1685387 although it's related. toshi, would you take a look?

Comment 4

[Toshihito Kikuchi [:toshi]]

The recent tab unloading feature is that tabs are unloaded one by one while the system memory is low. If the memory usage is normal, no tabs will be unloaded by this feature, so it will not be triggered so often.

Do you have the steps to reproduce the situation? I did the following steps, but about:restartrequired was not displayed. Even after tab unloading and nightly update, I could continue browsing on the unloaded tab.

1. Download an old Nightly package from https://download-origin.cdn.mozilla.net/pub/firefox/nightly/ and install it
2. Open some tabs in a private window
3. Check for updates and wait until the latest Nightly is installed
4. Go to about:unloads in a new tab in a normal window and unload a private window's tab (This simulates the same behavior as tab unloading)
5. Go to the unloaded tab and use it

On your side, you can turn off this tab unloading feature by setting browser.tabs.unloadOnLowMemory to false in about:config. Can you see if the same situation happens when the feature is off?

Comment 5

[:Gijs (he/him)]

(In reply to Toshihito Kikuchi [:toshi] from comment #4)

The recent tab unloading feature is that tabs are unloaded one by one while the system memory is low. If the memory usage is normal, no tabs will be unloaded by this feature, so it will not be triggered so often.

Do you have the steps to reproduce the situation? I did the following steps, but about:restartrequired was not displayed. Even after tab unloading and nightly update, I could continue browsing on the unloaded tab.

Your steps include updating with Nightly itself; in the reporter's case, Nightly (or Firefox) is updated by the package manager. This replaces Firefox's files, such that we cannot open new processes anymore, and we show the warning in the screenshot when the user opens new tabs for which we need new processes - or, it appears, if we've unloaded tabs and they then get reselected.

Could we consider not automatically unloading private tabs?

Comment 6

[Toshihito Kikuchi [:toshi]]

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

Your steps include updating with Nightly itself; in the reporter's case, Nightly (or Firefox) is updated by the package manager. This replaces Firefox's files, such that we cannot open new processes anymore, and we show the warning in the screenshot when the user opens new tabs for which we need new processes - or, it appears, if we've unloaded tabs and they then get reselected.

Oh, I see. Thanks for pointing it out.

Could we consider not automatically unloading private tabs?

I agree it's needed and it would also be beneficial if there is a way to avoid tab unloading for specific tabs without disabling the feature via about:config.

Comment 7

[Toshihito Kikuchi [:toshi]]

Attachment: Bug 1751366 - Never unload tabs in a private window. r=NeilDeakin

Comment 8

[Clément Lefèvre]

I might give a shot at reproducing on next nightly update on another computer, with a safer profile (where I got the issue is one I wouldn't mess with on nightly). But one "alternative", might at the very least to still print the url in the url bar (to copy and paste) or, even better, allow the user to bookmark it even if the reload fails. Because here, what happened was that tab reloaded with the page shown above, but the worse was that the url bar was empty, so that clicking the tab meant losing it.

Comment 9

[:Gijs (he/him)]

(In reply to Clément Lefèvre from comment #8)

I might give a shot at reproducing on next nightly update on another computer, with a safer profile (where I got the issue is one I wouldn't mess with on nightly). But one "alternative", might at the very least to still print the url in the url bar (to copy and paste) or, even better, allow the user to bookmark it even if the reload fails. Because here, what happened was that tab reloaded with the page shown above, but the worse was that the url bar was empty, so that clicking the tab meant losing it.

Can you file a separate bug for this? We should fix it even if this bug is fixed by not unloading private tabs, because I assume the same issue (ie missing URL bar and thus session restore info) affects non-private tabs, which will keep doing this.

Comment 10

[Clément Lefèvre]

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

(In reply to Clément Lefèvre from comment #8)

I might give a shot at reproducing on next nightly update on another computer, with a safer profile (where I got the issue is one I wouldn't mess with on nightly). But one "alternative", might at the very least to still print the url in the url bar (to copy and paste) or, even better, allow the user to bookmark it even if the reload fails. Because here, what happened was that tab reloaded with the page shown above, but the worse was that the url bar was empty, so that clicking the tab meant losing it.

Can you file a separate bug for this? We should fix it even if this bug is fixed by not unloading private tabs, because I assume the same issue (ie missing URL bar and thus session restore info) affects non-private tabs, which will keep doing this.

What do you mean? Because I didn't encounter issues with non-private tab as I can just restart browser and restore the session.

Comment 11

[:Gijs (he/him)]

(In reply to Clément Lefèvre from comment #10)

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

(In reply to Clément Lefèvre from comment #8)

I might give a shot at reproducing on next nightly update on another computer, with a safer profile (where I got the issue is one I wouldn't mess with on nightly). But one "alternative", might at the very least to still print the url in the url bar (to copy and paste) or, even better, allow the user to bookmark it even if the reload fails. Because here, what happened was that tab reloaded with the page shown above, but the worse was that the url bar was empty, so that clicking the tab meant losing it.

Can you file a separate bug for this? We should fix it even if this bug is fixed by not unloading private tabs, because I assume the same issue (ie missing URL bar and thus session restore info) affects non-private tabs, which will keep doing this.

What do you mean? Because I didn't encounter issues with non-private tab as I can just restart browser and restore the session.

OK, now I'm confused - the URL bar is empty, and the content area shows the "we need to restart" page - but if you restart the browser and restore the session, we correctly restore the right URL? That seems... surprising. Still, continuing to show the correct URL in the URL bar before the restart would still be valuable.

Comment 12

[Clément Lefèvre]

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

(In reply to Clément Lefèvre from comment #10)

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

(In reply to Clément Lefèvre from comment #8)

I might give a shot at reproducing on next nightly update on another computer, with a safer profile (where I got the issue is one I wouldn't mess with on nightly). But one "alternative", might at the very least to still print the url in the url bar (to copy and paste) or, even better, allow the user to bookmark it even if the reload fails. Because here, what happened was that tab reloaded with the page shown above, but the worse was that the url bar was empty, so that clicking the tab meant losing it.

Can you file a separate bug for this? We should fix it even if this bug is fixed by not unloading private tabs, because I assume the same issue (ie missing URL bar and thus session restore info) affects non-private tabs, which will keep doing this.

What do you mean? Because I didn't encounter issues with non-private tab as I can just restart browser and restore the session.

OK, now I'm confused - the URL bar is empty, and the content area shows the "we need to restart" page - but if you restart the browser and restore the session, we correctly restore the right URL? That seems... surprising. Still, continuing to show the correct URL in the URL bar before the restart would still be valuable.

Yes I believe it correctly restored everything that wasn't in private tabs. Private window on the other hand lost everything, which is intended for a restart.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8da89fe3d51f
Never unload tabs in a private window.  r=NeilDeakin

Comment 14

[Clément Lefèvre]

But considering unloading worked well in private windows if not under pending update circumstances, maybe this could be tackled by checking this first? Because in the end, unloading unused tabs is kinda useful (it could deserve to mark some as to not be unloaded, but that's yet another story for another bug).

Comment 15

[:Gijs (he/him)]

(In reply to Clément Lefèvre from comment #14)

But considering unloading worked well in private windows if not under pending update circumstances, maybe this could be tackled by checking this first?

I don't think we have a good way of checking the "pending update" state, when the update is not initiated by Firefox. We only realize that we are having this issue when we try to create a new child process and realize that the files on disk have been changed. Kirk, is that right?

(Checking the files every time we consider unloading tabs would introduce file IO costs which seems counterproductive.)

Comment 16

[Robin Steuber (they/them) [:bytesized]]

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

I don't think we have a good way of checking the "pending update" state, when the update is not initiated by Firefox.

That's correct.

We only realize that we are having this issue when we try to create a new child process and realize that the files on disk have been changed. Kirk, is that right?

Yeah, if you see the "Sorry. We just need to do one small thing to keep going" message, you don't have a pending update, the files at the install path have already been updated. When an update is pending, we show a friendlier "Update Available - Restart Now" message that appears in a doorhanger rather than taking over the tab.

(Checking the files every time we consider unloading tabs would introduce file IO costs which seems counterproductive.)

I feel like I should note that, even if we did do this, it couldn't be 100% effective. When we go to unload a tab, we could check that our files haven't been updated out from under us. But we wouldn't be able to know that they won't be updated in the near future.

Comment 17

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/8da89fe3d51f

Comment 18

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

The patch landed in nightly and beta is affected.
:toshi, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.

For more information, please visit auto_nag documentation.