Not all Firefox extensions are excluded from being opened in a temporary container

• Temporary Containers Version: 1.8 (latest as of issue)
• Firefox Version: 78.1.0 (latest ESR as of issue)

Actual behavior

Tampermonkey settings do not work well (temporary container) uBlock Origin settings work well (non-temporary)

Expected behavior

Detect all moz-extension://long random UUID follows, as unique URLs that are not websites but Firefox Addon URLs inside your browser.

Steps to reproduce

1. Have Tampermonkey installed.
2. Go to settings
3. it is a temporary container and settings cannot be exported unless you spawn a non-temp tab and manually go to the settings URI

Notes

I love your addon! All is good, just tweak the detection a bit please. Why does it know ublock is on the settings page, but not Tampermonkey?

You’ll find a way and thanks for developing this! 😃

[stoically]

I take your word for it. Thought scanning the URL is possible, but it would probably create a delay anyway.

It “can’t be done” was meant in the sense that it wouldn’t make sense for TC to implement something like that, because its a valid use case to open moz-extension:// URLs in different containers. Technically it might be possible with some workaround using the tabs API, though, it wouldn’t work using the webRequest API.

Makes sense now why it doesn’t work for all extensions.

It depends on which permissions an Add-on has and how the particular Add-on has implemented opening the settings page.

Technically it is open source, just the current version is not being released anymore.

AFAIK it’s proprietary since a few years. https://addons.mozilla.org/en-US/firefox/addon/tampermonkey/license/ basically just says “All rights reserved”. Where does it say it’s “technically open source”?

Thanks for your help, it is no big issue for me. But my reasoning was it might be easier to check here, since other addons probably don’t like TC either when exporting settings.

Yeah, makes sense. However, please note that it isn’t TC which affects that behavior. If you open a permanent container tab (e.g. with long clicking new tab and choosing “Personal”), focus that tab and then open the settings page from Tampermonkey, you can observe the same issue.

Hitting ALT+N and have a normal tab is my way of choice.

Right, that works as well.

Feel free to close this as desired, unless you want to track it for personal reasons.

Yeah, I’ll close since I don’t think here’s something that could be done by TC.

Hope that helps!

[stoically]

Glad you like the Add-on!

That behavior can be influenced by the code that runs when the settings button in the Add-ons popup is clicked. In uBlock’s case it defaults to no container because they don’t have the cookies permission, in Tampermonkey’s case they have the cookies permission and should explicitly specify cookieStoreId: "firefox-default" (no container), as otherwise it inherits the container from the currently active tab. Can’t check their code because its proprietary. Might want to consider using an open alternative like Greasemonkey or Violentmonkey.

Opening moz-extension:// URLs in a specific container can be something that’s desired, e.g. in my Radical Add-on it allows having multiple user profiles. So generically disallowing extension pages to be opened in a TC can’t be done.