Addon broken in Waterfox Current (2019.10)

[Beck-919]

• Temporary Containers Version: 1.7
• Firefox Version: Waterfox Alpha 2019.10

Actual behavior

New tabs not opening in new containers (Automatically open is set)

Expected behavior

New tabs open in new containers

Steps to reproduce

1. Open new tab after ticking Automatic Mode in addon settings page
2. New tab opens normally, does not open in container

Notes

1st issue ever raised on github, please ask if any more details required. Issue not reproducing on normal Firefox

[stoically]

Could you check if you have the same issue as #332?

[Beck-919]

New tabs are set to Waterfox Home (Default).

I have also put up a post on the r/waterfox, so I will check from that side also

[stoically]

So I've checked and the reason is that Waterfox doesn't support browser.contextMenus.onShown, because it relies on a hopelessly outdated version of Firefox. I'm actually a bit reluctant to support that, but I'll check if its enough to make an exception-check for the presence of contextMenus.onShown.

[Beck-919]

Waterfox Current (gave wrong name as Alpha) 2019.10 is based on Firefox 68.0b1, that too doesn't support it?

[stoically]

Ah, didn't realize there's an updated version. TC requires Firefox 67, so it should work fine. The reason it doesn't work is the fix that was made for Icecat in #307. Waterfox returns { name: "Waterfox", vendor: "Mozilla", version: "68.0", .. } on the browser.runtime.getBrowserInfo() API, but the container ids are still prefix with firefox- instead of waterfox-. I'd say that should be fixed in Waterfox, but I look into adding an exception in TC to make it work.

[Beck-919]

Ok, thanks. Please leave a comment once you have fixed it. I will update and return to you then.

[stoically]

FWIW, a workaround to get it to work now for a running Waterfox until the browser is restarted, is executing tmp.containerPrefix = 'firefox'; on the debug console.

[Beck-919]

Ok, I will do that for now. But please do fix it.

[stoically]

Just realized, there's a workaround that even survives browser restarts:

tmp.storage.local.containerPrefix = 'firefox';
tmp.storage.persist();

on the debug console should do the trick.

[Beck-919]

Sure, thanks. But it won't matter once the fix is released right? Or will I have to revert it back?

[stoically]

Glad to help. A possible fix would do the same, so you're good.

[Beck-919]

Worked like a charm. Will wait for the fix. For now all is well :)

[Beck-919]

Don't know if it is related to this issue, but the containers are no longer auto-deleting on browser restart (even after 2 minutes in my settings).

On a side note, will 'Multi-Account Containers' interfere with the addon's mechanics?

[stoically]

Could you provide a debug log for "While the Add-on initializes"? The cleanup on browser start should start after 10seconds.

On a side note, will 'Multi-Account Containers' interfere with the addon's mechanics?

They should work fine together, there's some code in TC and MAC to make them compatible.

[Beck-919]

This are the results:

For 'tmp.log.DEBUG=true', I was getting this:

Then I saw 'localStorage.setItem('debug', true)', so got this:

But after restart again got the log waterfox.log

[stoically]

Thanks. Unfortunately it seems to just not start the cleanup, not sure why. Could you try executing

tmp.log.DEBUG = true;
tmp.cleanup.cleanup(true);

on the debug console and see if it removes the containers? If it does, it seems that for some reason the runtime.onStartup event doesn't fire correctly or something.

[stoically]

Also, every 10 minutes there's a fallback cleanup interval. So leftover TCs should get removed 10 minutes after startup if the cleanup directly after startup fails.

[Beck-919]

It just started this: waterfox2.log

Also I had created a new named container about 15 minutes ago, the tmp containers above are still present.

[stoically]

Error: An unexpected error occurred undefined, well, now that's what I call a helpful error message, thanks Firefox (or maybe Waterfox) :D

If I get the chance I'll try to debug that, until then unfortunately no container removal for Waterfox users.

[Beck-919]

Ok, if you ever fix it please do update the issue. Also please do fix it, Waterfox is a pretty good fork of Firefox, one of the most stripped down.

[samvde]

Just realized, there's a workaround that even survives browser restarts:

tmp.storage.local.containerPrefix = 'firefox';
tmp.storage.persist();

on the debug console should do the trick.

Many thanks, I love your extension. This worked flawlessly.

[akdev1l]

Just for reference, this issue also impacts LibreWolf. The same fix applies. Thank you.

[akdev1l]

created an issue on LibreWolf's tracker: https://codeberg.org/librewolf/issues/issues/2669

my thoughts: other extensions may depend on the default values, perhaps Temporary Containers should retrieve this prefix from the execution environment instead of assuming the pattern ${getBrowserInfo().Name}-default is correct

[akdev1l]

gave this a shot: https://github.com/stoically/temporary-containers/pull/648

it's ugly, lmk if you'd be open to merge

[Gitoffthelawn]

gave this a shot: #648

it's ugly, lmk if you'd be open to merge

Sadly, stoically passed away, so a merge will not be possible.

You may be interested in taking a look at this fork: https://github.com/GodKratos/temporary-containers/

[akdev1l]

thank you for the heads up, very sad to hear