1661951 - Pinned Container Tabs Reset to Non-Container versions (with same URLs) every time Firefox Nightly 82.0a1 restarts for updates on MacOS 10.15.6

Status: RESOLVED WORKSFORME

(Core :: Security, defect)

Description

[Udbhav Tiwari]

I run Firefox Nightly 82.0a1 (2020-08-29) (64-bit) on MacOS 10.15.6

Summary: This bug report is about how, since mid-July 2020, every time I restart Nightly so it can install the daily update (about once a day) all the tabs that I have opened as pinned container tabs end up resetting to their vanilla, non-container versions. This ends up wasting 2-3 minutes every time I restart Nightly and also dis-incentivizes updating the browser, as detailed below.

Detail: I usually have 3-4 tabs running in work containers that I pin in my main nightly window. All of them are opened in the "Work" container and usually contain my work email, calendar and company intranet. Since mid-July 2020, every time I agree to restart Nightly so it can install its daily update, all of these pinned tabs reset from being container tabs to vanilla, non-container, tabs with the same URLs as prior to the restart.

Impact: As a result of this, I then have to close all these pinned tabs, open new work container tabs, type in URLs and pin them again. I need to end up doing this at least once a day. For example, the pinned tab that opens my work inbox - which is Gmail based - opens my personal inbox after the restart as it is no longer a container tab.

This dis-incentivizes me from restarting and updating Nightly (bad for security and stability) and forces me to spend a few minutes every day redoing the same process. The problem did not occur before mid-July 2020, when pinned container tabs used to persist across app restarts, system reboots and even crashes.

Caveat: The problem doesn't impact non-pinned tabs, which persist containers across restarts, so the problem seems unique to pinned tabs.

Requested Fix: Please do look into why this is occurring and it'll be great if this could be fixed to reallow pinned container tabs to persist (rather than reset) across app restarts. This will allow more people to use Nightly as a daily driver. I'm happy to share any logs or other details that will be helpful in resolving this from my end. Thank you!

Comment 1

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Daniel Veditz [:dveditz]]

This sounds horribly inconvenient! I'm sorry you're having this problem. This is a normal configuration for me (e.g. two pinned GMail tabs in different containers) and haven't seen this problem. This makes me suspect some kind of data problem. The fact that is only happens to pinned tabs, and other tabs in the same container do persist in that container across restarts kind of blows all my theories up.

I don't work on this feature, but afaik there are two data stores in play:

• sessionrestore data keeps track of all your tab state
• web extension data keeps track of information about containers

sessionrestore is remembering the tabs and their pinned state, and the container state for other tabs. you're deleting the old broken tabs and creating new pinned tabs so any malformed data in a specific entry that's confusing Firefox should be gone.

Mapping sessionrestore container ID to your list of containers seems to be working fine for other tabs.

I'm half tempted to suggest a Firefox refresh (profile rebuild) but that will definitely trash all your container info (along with all your other extensions), and I'm not sure if it preserves all your open tabs or not.

Maxx or Luke: any ideas?

Comment 3

[Maxx Crawford [:maxx]]

Oh, wow.

Can you include steps to reproduce? I'm on the same setup (MacOS 10.15.6 running Nightly) and have not had this issue. Additionally, can you provide any other add-ons you have installed?

Thanks!

Comment 4

[Udbhav Tiwari]

About three days ago, this problem fixed itself!

I restarted my Firefox installation for a typical daily update install on Sep 17 and my pinned tabs reappeared as expected! I didn't change any settings within Firefox and haven't tried any other mitigation measures post filling this bug.

The usual steps I followed (before the bug fixed itself) were:

1.) Open Firefox Nightly
2.) Open 3 container tabs which are logged into Gmail, Google Calendar and Google Docs respectively (in the work category)
3.) Pin these tabs and proceed with work as usual
4.) When Nightly lets me know there is a new update, restart the browser to install the update within a few hours of such a message
5.) Upon restarting the browser, the same URLs are present in the same pinned tabs as before but this time without any container limitations/features and therefore working as a normal tab (logging into my personal account instead of my work one, in this instance)

The add-ons I have installed are (sorry for the long list): 1Password, AutoTab Discard, Cisco WebEx, Cookie AutoDelete, Decentraleyes, Enchancer for YouTube, Facebook Container, Firefox Multi-Account Containers, Firefox Pioneer, FlagFox, HTTPS Everywhere, Mailenvelope, Momentum, Pioneer V2, Privacy Badger, Privacy Possum, Reddit Enhancement Suite, RegretsReporter, TrafficLight (BitDefender), uBlock Origin, Wayback Machine, Web Archives, Wikiwand and Zoom Scheduler.

Hope all of this helps and I'll be sure to update the bug if the problem begins to reoccur!

Comment 5

[Udbhav Tiwari]

As an update, the issue has started reoccurring since yesterday (23 Sep) night. Upon restarting Firefox Nightly in general or for an update, the pinned tabs reset to their non-container versions (with the same URLs) when the browser opens up again. The problem went away for about 8-10 odd days now seems to have started reoccurring consistently again.

Comment 6

[Daniel Veditz [:dveditz]]

Maxx: are Facebook Container and Firefox Multi-Account Containers compatible or do they fight?

Comment 7

[Maxx Crawford [:maxx]]

They are compatible.

We have specific code detection/logic in Facebook Container to respect user settings from Multi-Account Containers. I'm not sure if M-AC has code for it to play well with FBC, but I also don't think it's necessary. M-AC just treats FBC like an existing, non-editable (through its own tools) container.

To graph it out, I'm thinking of two types of users:

• Multi-Account Containers user who installs Facebook Container
• Facebook Container user who installs M-AC.

Comment 8

[Wayne Mery (:wsmwk)]

Udbhav,
Does this still reproduce for you?

Comment 9

[Danny Colin [:sdk]]

:wsmwk for what it's worth, I can't reproduce it with the builtin container feature and a tried a few versions back with mozregression on Linux. This might be an issue with how OP addons are configured even tho FBC and MAC should be compatible with each others.

To further investigate, I think OP should create a fresh profile, enable the builtin feature (without installing any addon) and try to reproduce this issue. If they can't, they should try again but this time with MAC and FBC installed and file an issue on MAC repo if needed.

So, if we don't get any feedback from OP for another week, I think we can go ahead and close this as WORSFORME.

Comment 10

[Wayne Mery (:wsmwk)]

Thanks Danny