Number of containers stuck on tmp 66 even after restarts

[ghost]

• Temporary Containers Version: 0.103 and before
• Firefox Version: 68 developer edition
• Operating System + Version: Win 10 x64 v1903
• Non-default Options/Preferences in Temporary Containers: automatic mode
• Other installed Add-ons + Version: none that use containers

Actual behavior

My container number doesn't go back to tmp 1 despite closing all tabs, waiting long enough and restarting firefox.

Expected behavior

At some point I should begin with tmp 1, tmp 2, ... etc again.

Is there a way to manually tell your extension to delete every container? I really love browsing with it and it protected me already from 100k+ cookies.
Edit: I know reinstalling it an re-importing settings would work, but I don't want to lose statistics.

Steps to reproduce

1. Use the addon in automatic mode for an extended period of months.
2. ..
3. ..

Notes

I will provide logs once home again.

[stoically]

Glad you like it, and 100k+ is a bunch, hah.

In this case a debug log would indeed be helpful, since I'm not sure how this happens. It might make sense to set the container deletion time to instant in the preferences, so reproducing your issue would simply mean opening one tmp container and then closing it, waiting about ~30s and copying the log. Thanks!

[ghost]

Visited:
http://www.koreaherald.com/

Log:
https://pastebin.com/TXTBBXDp

[stoically]

Thanks, unfortunately no obvious problem visible. Could you put tmp.storage.local.tempContainers and tmp.storage.local.tempContainersNumbers into the console (where you entered log.DEBUG = true) and tell me what it replies?

[ghost]

tmp.storage.local.tempContainers
{…}
​"firefox-container-10": Object { name: "tmp72", color: "blue", icon: "circle", … }
​"firefox-container-7": Object { name: "tmp70", color: "green", icon: "circle", … }
​"firefox-container-9": Object { name: "tmp71", color: "turquoise", icon: "circle", … }
​<prototype>: Object { … }

tmp.storage.local.tempContainersNumbers
(73) […]
​0: 1
​1: 10
​2: 11
​3: 12
​4: 13
​5: 14
​6: 15
​7: 16
​8: 17
​9: 18
​10: 19
​11: 2
​12: 20
​13: 21
​14: 22
​15: 23
​16: 24
​17: 25
​18: 26
​19: 27
​20: 28
​21: 29
​22: 3
​23: 30
​24: 31
​25: 32
​26: 33
​27: 34
​28: 35
​29: 36
​30: 37
​31: 38
​32: 39
​33: 4
​34: 40
​35: 41
​36: 42
​37: 43
​38: 44
​39: 45
​40: 46
​41: 47
​42: 48
​43: 49
​44: 5
​45: 50
​46: 51
​47: 52
​48: 53
​49: 54
​50: 55
​51: 56
​52: 57
​53: 58
​54: 59
​55: 6
​56: 60
​57: 61
​58: 62
​59: 63
​60: 64
​61: 65
​62: 66
​63: 67
​64: 68
​65: 69
​66: 7
​67: 70
​68: 71
​69: 8
​70: 89
​71: 9
​72: 72
​length: 73

Thanks for investigating this so thoroughly!

Edit: sorry for expanding it this much, but I noticed an interesting pattern of single digit numbers, may be important.

[stoically]

Interesting, so it cleaned the containers correctly, but didn't remove the number. I'll add a fallback cleanup for that case, since I'm not sure how that even happens.

To fix it now, you could do

tmp.storage.local.tempContainersNumbers = [];
tmp.storage.persist();

If not all tmp containers are removed before doing that you might get duplicated numbers for them once, if you want to avoid that, let TC remove all tmp containers first.

[ghost]

Oh thank you a lot that worked!

Maybe you could add a tickbox:
[x] Clear all containers on Firefox exit [Warning: Wipes all session data]

So it only runs on shutdowns and only affects those who want everything gone on exit.

Edit:
ublock Origin, temporary containers, umatrix, https everywhere and a userscript manager are the five must have addons. you are doing god's work.

[stoically]

Thanks!

TC already removes all containers on Firefox startup if they have no open tabs anymore. There's no reliable way for Add-ons to hook into the Firefox shutdown.

Btw, just in case you didn't know, GitHub flavoured markdown supports collapsed blocks for e.g. longer debug data, like so:

<details>
<summary>tmp.storage.local.tempContainersNumbers</summary>

...
</details>

[ghost]

Indeed I did not know this yet. Sorry if I didn't export the full structure of tmp.storage.local.tempContainers as I already had troubles to expand it. Wish one could write directly to a file like in BASH. Do you still need the full dump? Else I'm happy you took your time to help me!

[stoically]

The information you provided was already helpful, thanks for being responsive!

[stoically]

v1.0beta15 includes a refactoring which should make sure that this doesn't happen anymore - and additionally a fallback cleanup for the worst-case.