Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Temporary Containers Automatic Mode doesn't work on Zen Browser #172

Open
1 task done
Muko-Tabi opened this issue Aug 6, 2024 · 7 comments · May be fixed by #2411
Open
1 task done

Temporary Containers Automatic Mode doesn't work on Zen Browser #172

Muko-Tabi opened this issue Aug 6, 2024 · 7 comments · May be fixed by #2411

Comments

@Muko-Tabi
Copy link
Contributor

What happened?

Temporary Containers Extension Issue

Extension Details

Issue Description

The Temporary Containers extension is designed to automatically assign new tabs to temporary containers when the "Automatic Mode" setting is enabled. This feature works as expected in regular Firefox up to the current Developer Edition as of now, even if the extension is outdated. However, when using the Zen browser the "Automatic Mode" feature doesn't work.

Steps to Reproduce

  1. Install the Temporary Containers extension in Firefox.
  2. Open the Temporary Containers extension settings.
  3. Go to General and tick "Automatic Mode".
  4. Open a new tab.

Expected Result

When opening a new tab in step 4, the Temporary Containers extension should automatically assign the tab to a temporary container.

Actual Result

When opening a new tab in step 4 in Zen Browser, the Temporary Containers extension does not automatically assign the tab to a temporary container.

  • Would be nice if there's a workaround or the project can integrate the extension into it, since this is currently why I'm still using normal Firefox. Thanks in advance :D

Reproducible?

  • I have checked that this issue cannot be reproduced on Mozilla Firefox.

Version

Alpha build - 1.0.0-a.12

Severity impact

Medium, Enhancement

What platform are you seeing the problem on?

Linux, Windows

Relevant log output

No response

Copy link

github-actions bot commented Sep 8, 2024

This issue is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale label Sep 8, 2024
@HarryHeres HarryHeres removed the stale label Sep 9, 2024
Copy link
Member

Does it still happen?

@Muko-Tabi
Copy link
Contributor Author

yup still happen, same with Floorp and Librewolf as well

@howyay
Copy link

howyay commented Sep 25, 2024

It still occurs on Zen, but works normal for me on Librewolf

@mr-cheff
Copy link
Member

mr-cheff commented Oct 5, 2024

yup still happen, same with Floorp and Librewolf as well

it's probably the extension's fault then, no?

@somerandom2
Copy link

somerandom2 commented Oct 13, 2024

yup still happen, same with Floorp and Librewolf as well

it's probably the extension's fault then, no?

@mauro-balades
It is working on Librewolf

Screen.Recording.2024-10-13.at.19.02.43.mov

@lbrooney
Copy link

lbrooney commented Oct 30, 2024

I think I found a solution. Inspecting the Temporary Containers, you will immediately notice a lot of uncaught errors from showOrHide caused by L4943. The extension is trying to get a container with id firefox-default, but that does not exist.

Examining Temporary Containers source code, showOrHide is found in pageaction.ts with the line causing the throw at L43. For why it's throwing, in Firefox you never reach the else instead the if else on L31 is executed. In Zen that if else doesn't execute because the extension checks whether the default cookiestore id is being used by getting the browsers name which gives zen and appending -default, but the default cookiestore id is firefox-default. The else if doesn't execute as zen-default does not equal firefox-default and instead the else executes which causes the error.

Setting global.DEFAULT_STORE in /toolkit/components/extensions/parent/ext-toolkit.js to zen-default makes Automatic Mode in Temporary Containers functional.

I can't comment whether this fix breaks other container extensions. If they hardcoded checking cookieStoreId against firefox-default, then this fix would break them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
6 participants