No profiles shown when using Firefox container tabs

[robgonnella]

Describe the bug
When using container tabs on Zen browser (firefox), no profiles are loaded in the popup menu despite successful save in configuration view.

To Reproduce
Steps to reproduce the behavior:

1. Launch Zen browser
2. Create new container tab
3. Go to AWS console
4. Open extension
5. No profiles load
6. Go to Configuration
7. Save valid configuration
8. Go back to AWS console and open extension
9. No profiles load

Expected behavior
Expect configured profiles to load for container tabs

Screenshots
If applicable, add screenshots to help explain your problem.

Environment

• OS: MacOS 26.4.1
• Browser: Zen (firefox)
• Version: 1.19.8b (Firefox 149.0.2) (aarch64)

[robgonnella]

Installing the extension locally, I was able to confirm that the following fixes the issue for me

 export async function findTargetProfiles(ctx) {
   try {
-    return await retrieveTargetProfilesFromDB(ctx);
-  } catch (err) {
-    // Firefox private browsing
-    return await retrieveTargetProfilesFromLztext(ctx);
+    const profiles = await retrieveTargetProfilesFromDB(ctx);
+    if (profiles.length > 0) return profiles;
+  } catch (_) {
+    // IndexedDB not available (Firefox private browsing or container isolation)
   }
+  return await retrieveTargetProfilesFromLztext(ctx);
 }

[robgonnella]

@tilfin gentle ping - Thanks for all your hard work on this project, I use it daily! Was hoping to get some eyes on this as I've grown increasingly reliant on container tabs in firefox.

I've been running locally, with the fix above, as a temporary extension for a few days now without issue. It's just annoying that it gets cleared out every time I quit the browser so I was hoping to get a fix landed upstream.

[kishaningithub]

@robgonnella How did you update the extension code in your local?

[robgonnella]

Since there hasn't been any response to this I decided to post a patched firefox version under my own account. You can access it here: https://addons.mozilla.org/en-US/firefox/addon/rgon-aws-extend-switch-roles/?utm_source=addons.mozilla.org&utm_medium=referral&utm_content=search

[tilfin]

@robgonnella Thanks for the report.

I tried to reproduce this using the latest Firefox with Firefox Multi-Account Containers, as well as the latest Zen Browser, both with default settings. Unfortunately, I couldn’t reproduce the issue in either case.

The profiles were shown correctly in the popup when opening the AWS Console in a container tab.

I’m wondering if IndexedDB might be isolated or unavailable in your environment due to a browser setting or another add-on. Do you have any non-default privacy/security settings enabled, or any other add-ons installed that might affect storage, containers, or privacy?

If possible, could you also try reproducing it with a fresh browser profile and only this extension installed?

[robgonnella]

Hi @tilfin thanks for writing back. I just updated to latest Zen and it's still not working for me, BUT based on the fact that it worked for you I tried playing around more to see if there is some magic setting that's causing issues.

My current setup uses 2 spaces and each space is set to use a specific container as default for all tabs. So I have a Work space that defaults to using "work" container for tabs, and a personal space that uses "personal" containers for tabs. Within my "work" space I also have 2 pinned tabs that each use different containers for 2 different AWS accounts. With this setup I could not get this extension to work. The configuration would save but then no profiles would render when clicking within AWS console.

Based on the fact that it worked for you, I decided to create a new "test" space that does not use any containers. From that space I created a non-container tab, saved the config, and now it works everywhere! I deleted that space and it still works in my other spaces with all the different container tabs!

So it seems maybe once it's loaded correctly once, it just works, but there is an issue with saving brand new config in a space that is set to always use "containers". I guess this makes it kind of hard to reproduce but either way the suggested change above did seem to address the issue in all cases.

[tilfin]

@robgonnella Thanks for testing this.

After investigating further, I think the issue is not just that IndexedDB is unavailable or empty.

If the options page is opened in a container tab and the user saves updated settings there, the latest config text is written to local storage, but the IndexedDB later read by the popup does not seem to be updated. It is probably being written to a container-specific IndexedDB, or otherwise not to the same DB instance the popup uses.

The popup appears to keep reading the same shared IndexedDB regardless of whether the current tab is in a container or not. As a result, it can keep showing stale profile data even though the latest config text was saved successfully.

Because of that, the proposed fallback helps only when the shared IndexedDB has never been populated at all. If a user first saved settings from a non-container tab, the shared IndexedDB already contains older data. Later saves from a container tab update local storage, but the popup continues reading the old IndexedDB entries, so the fallback is never triggered.

So the real problem is not only missing DB data, but also stale DB data that no longer matches the latest saved configuration.

I’ll think through a better fix that accounts for this behavior.

[robgonnella]

Ah great insights @tilfin , thank you! Past getting the initial save to populate in the popup, I never tested updating the config after! Thank you for your work on this. I'll keep playing around with this too and I'll let you know if I come up with anything.