fogotype.<pid> directory is created at every startup of Nightly, but not deleted when the browser closes
Categories
(Toolkit :: Telemetry, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox72 | --- | unaffected |
| firefox73 | --- | unaffected |
| firefox74 | --- | disabled |
| firefox75 | --- | fixed |
People
(Reporter: alice0775, Assigned: chutten)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
Reproducible : 100%
Steps to reproduce:
- Start Nightly74.0a1
- Quit Nightly
- Observe temp directory
- Repeat from step 1
Actual Results:
fogotype.xxx directory are created indefinitely
Expected Results:
The directory should be deleted when the browser closes
| Assignee | ||
Comment 1•6 years ago
|
||
Gah, sorry about that. I should've caught that in review. We should clean that up.
The directories are safe to delete and Firefox's behaviour should be unaffected. It is an artefact of a piece of prototype code.
Updated•6 years ago
|
Comment 2•6 years ago
|
||
That already was the case before we switched to "fogotype.xyz" directories (that is: /tmp/db and /tmp/events stuck around).
Right now the fogotype doesn't handle lifecycle at all, so it doesn't know about shutdown and because it does run in its own thread, we don't have any good way of notifying it just yet.
Dropping priority because I won't get to it before All Hands. After that we should have a plan how to move forward with the prototype (e.g. whether we make it a more serious prototype first or rip it out)
Updated•6 years ago
|
Comment 3•6 years ago
|
||
Same bug in thunderbird Daily since 2020-01-28.
Would this bug also account for the multitude of mat-debug-nnnn.log files also appearing in the %temp% directory?
| Reporter | ||
Comment 5•6 years ago
|
||
(In reply to Mark from comment #4)
Would this bug also account for the multitude of mat-debug-nnnn.log files also appearing in the %temp% directory?
no
mat-debug-nnnn.log files seems to be created by a Microsoft Program(MicrosoftOffice) called LocalBridge.exe.
Comment 6•6 years ago
|
||
(In reply to Chris H-C :chutten from comment #1)
Gah, sorry about that. I should've caught that in review. We should clean that up.
The directories are safe to delete and Firefox's behaviour should be unaffected. It is an artefact of a piece of prototype code.
Is there anything that needs to be done, or will whatever the fix is here delete all the directories already created?
Comment 7•6 years ago
|
||
Jan Erik, is that a nightly-only regression or will it impact 74 beta with the merge next Monday? Thanks
Comment 8•6 years ago
|
||
It should be nightly only (compile-time gated).
As this is the first time we're doing it, :chutten is keeping an eye out on the beta merge next week and is ready to revert the patches there if we find out it's not working as intended.
This is definitely not planned to land in beta/release.
Comment 9•6 years ago
|
||
With bug 1614923 landing the FOGotype will go away and thus not create new temporary directories.
We're not going to clean up existing temporary directories.
Comment 10•6 years ago
|
||
(In reply to Jan-Erik Rediger [:janerik] from comment #9)
We're not going to clean up existing temporary directories.
Any reason for this?
FYI - Windows never automatically cleans TEMP directory by default, so Mozilla Firefox will leave its bloat which made hundreds of folders undeleted.
| Assignee | ||
Comment 11•6 years ago
|
||
I had a little extra bandwidth this week to look at this. This should be removed after a couple days/week of being in tree.
| Assignee | ||
Updated•6 years ago
|
| Assignee | ||
Comment 12•6 years ago
|
||
The FOGotype put some dirs into the os tmpdir. Generally we think this is
harmless, but it doesn't take too much code to safely try to clean up.
FOGotype was nightly-only and is now disabled, so this patch should only
need to live for a little while before reverting.
Comment 13•6 years ago
|
||
Comment 14•6 years ago
|
||
| bugherder | ||
Comment 15•6 years ago
|
||
This is not an issue in beta (74) per comment 8.
Updated•6 years ago
|
Description
•