I almost exclusively use private tabs and had quite a few of them open at any time for things I was working on. But apparently since I’ve last updated the default behavior changed to close private tabs and the option to keep them open was removed.
Digging into it, I’ve found the bug report in the link. The last entry in the bug report is concerning:
It looks like this was discussed in FXIOS-8672, although I don’t have access to that JIRA to take a look at the discussion.
Of the three PRs that I see that reference FXIOS-8672, one of them mentions:
I’ve intentionally kept this PR as simple as possible so we can release it and then be sure there is no major blow back from users. If we need to roll back it should be very simple in the current state.
I’m not sure what would count as “major blow back” but there is at least some hope that this functionality can be restored.
I agree with @garnetred that this behaviour isn’t limited to force closing the app.
Silently changing a behavior, especially one that is in other web browsers, is a bit user-hostile and I understand the frustration.
On the other hand, privacy-wise this change is good, since it was likely storing the incognito tabs (browser state) in the app storage and was likely retrievable by forensics tools (ie: Cellebrite).
I’d rather have the browser state of incognito tabs stored in RAM at all time.
I feel like those affected are using incognito tabs as a way to separate their browsing history. Maybe a more convenient option would be the ability to run multiple browser sessions on mobile instead of falling back on the incognito mode as a workaround.
They had an option to close the private tabs, which was on by default. I’ve changed it to off for a reason. Breaking people’s workflow for a false perceived gain in privacy is bull. Private tabs are just local storage cleaning tabs. Pretending this change improves privacy is nonsense.