Crashping crate does not respect disabled telemetry settings
Categories
(Toolkit :: Crash Reporting, defect, P2)
Tracking
()
People
(Reporter: mozilla, Assigned: afranchuk)
References
Details
Attachments
(9 external files, 1 obsolete file)
This appears to be a regression of Bug 2026650.
Firefox version:
140.15.0esr on Linux (64bits)
Telemetry is disabled:
datareporting.healthreport.uploadEnabled = false
No deletion_request is present under ~/.mozilla/firefox/Crash Reports/glean/; only files under pending_pings/ are created after the crash.
All telemetry-related options in Settings > Privacy & Security are also disabled,
including automatic crash report submission.
However, when Firefox crashes:
- a connection attempt to Mozilla telemetry servers is observed by the firewall;
- a new file is created in:
~/.mozilla/firefox/Crash Reports/glean/pending_pings/
Destination observed by firewall: incoming.telemetry.mozilla.org
CmdLine: curl --user-agent crashreporter/1.0.0 --header X-Telemetry-Agent: Glean/64.3.1 (Rust on Linux) --header Content-Encoding: gzip --header Content-Type: application/json; charset=utf-8 --header Content-Length: 1421 --header Date: Wed, 09 Sep 2026 16:xx:xx GMT --data-binary @- https://incoming.telemetry.mozilla.org/submit/firefox-crashreporter/crash/1/xxxxx....
This happens with a fresh crash under Firefox 140.15.0esr.
Expected:
No crash telemetry ping should be generated or submitted when telemetry is disabled considering "status-firefox-esr140: affected → fixed"
Actual:
A Glean pending ping is created and Firefox attempts a network connection after the crash.
|
Assignee | |
Comment 1•2 months ago
•
|
||
Thanks for your report! When did the crash occur? A crash that occurs prior to profile initialization will not have the profile information necessary to read the pref (and for that matter, any issue reading the prefs file will have the same result).
I use hundred of tab and firefox crash from time to time without explanation after days or weeks of usage. The crash that send the telemetry ping doesn't happen right after firefox startup if that was your question.
BTW, the SSD and filesystem containing my ~/.mozilla/firefox/ profile is healthy (I guess my pref are inside this directory)
It looks like the Bug 2026650 fix was not push on the 140.15.esr debian package
|
|
Assignee | |
Comment 3•2 months ago
•
|
||
https://phabricator.services.mozilla.com/D292422 in bug 2026650 landed in ESR 140.10, so it should be respecting the setting.
|
|
Assignee | |
Comment 4•2 months ago
|
||
If you manually force a crash (visit about:crashparent), do you see the same result (e.g. contact with telemetry servers and pending pings being created)?
yes, it try to send 3 "curl --user-agent crashreporter/1.0.0 ...." to incoming.telemetry.mozilla.org (DstPort 53)
|
|
Assignee | |
Updated•2 months ago
|
|
|
Assignee | |
Updated•2 months ago
|
|
|
Assignee | |
Comment 6•2 months ago
|
||
Can you share the log file at ~/.mozilla/firefox/Crash Reports/submit.log after the errant behavior?
|
|
Assignee | |
Updated•2 months ago
|
this is the content of my ~/.mozilla/firefox/Crash Reports/submit.log :
[ERROR crashreporter::net::ping] failed to send legacy ping: failed to create telemetry crash ping: missing TelemetryClientId
This is the content of ~/..mozilla/firefox/Crash Reports/glean/pending_pings/82c9760f-b382-47a7-94b6-41c6e4da9d93 (my client-id is redacted)
/submit/firefox-crashreporter/crash/1/82c9760f-b382-47a7-94b6-41c6e4da9d93
{"ping_info":{"seq":20,"start_time":"2026-09-09T18:24:44.000+02:00","end_time":"2026-09-10T16:40:37.185+02:00","reason":"crash"},"client_info":{"telemetry_sdk_build":"64.3.1","app_display_version":"1.0.0","os_version":"6.12","locale":"fr","app_build":"20260826142222","architecture":"x86_64","os":"Linux","first_run_date":"2025-10-18+02:00","build_date":"1970-01-01T00:00:00+00:00","client_id":"xxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxx"},"metrics":{"datetime":{"crash.time":"2026-09-10T14:40:37.177+00:00"},"object":{"crash.stack_traces":{"crash_type":"SIGSEGV / SEGV_MAPERR","crash_address":"0x0","crash_thread":0,"main_module":0,"modules":[{"base_address":"0x559446c9d000","end_address":"0x559446d2c000","code_id":"29fdd741de802a252ff14b67edde24cf8ae03593","debug_file":"firefox-esr","debug_id":"41D7FD2980DE252A2FF14B67EDDE24CF0","filename":"firefox-esr","version":"0.0.0.0"},{"base_address":"0x7fb36a400000","end_address":"0x7fb374088000","code_id":"dbb4b0124ed93bbd6041e12afdffb2747673357c","debug_file":"libxul.so","debug_id":"12B0B4DBD94EBD3B6041E12AFDFFB2740","filename":"libxul.so","version":"0.0.0.0"},{"base_address":"0x7fb37751c000","end_address":"0x7fb377703000","code_id":"c495b62edadd6c356265942ec1282d98058a7b41","debug_file":"libc.so.6","debug_id":"2EB695C4DDDA356C6265942EC1282D980","filename":"libc.so.6","version":"6.0.0.0"}],"threads":[{"frames":[{"module_index":1,"ip":"0x7fb370ec4e6e","trust":"context"},{"module_index":1,"ip":"0x7fb36d6bfe9a","trust":"cfi"},{"module_index":1,"ip":"0x7fb36d6c1c30","trust":"cfi"},{"module_index":1,"ip":"0x7fb36db3a823","trust":"cfi"},{"module_index":1,"ip":"0x7fb36db3772b","trust":"cfi"},{"module_index":1,"ip":"0x7fb36db37207","trust":"cfi"},{"module_index":1,"ip":"0x7fb36db43e26","trust":"cfi"},{"module_index":1,"ip":"0x7fb36db7dc51","trust":"cfi"},{"module_index":1,"ip":"0x7fb37052103c","trust":"cfi"},{"module_index":1,"ip":"0x7fb36dc5de0d","trust":"cfi"},{"module_index":1,"ip":"0x7fb36dc5d1b2","trust":"cfi"},{"module_index":1,"ip":"0x7fb36dc5d55f","trust":"cfi"},{"module_index":1,"ip":"0x7fb36dc5d9b4","trust":"cfi"},{"module_index":1,"ip":"0x7fb36d57a261","trust":"cfi"},{"module_index":1,"ip":"0x7fb36d576aab","trust":"cfi"},{"module_index":1,"ip":"0x7fb36d574f8a","trust":"cfi"},{"module_index":1,"ip":"0x7fb36d57518b","trust":"cfi"},{"module_index":1,"ip":"0x7fb36d57b912","trust":"cfi"},{"module_index":1,"ip":"0x7fb36d586f3e","trust":"cfi"},{"module_index":1,"ip":"0x7fb36d58a87d","trust":"cfi"},{"module_index":1,"ip":"0x7fb36dc607d0","trust":"cfi"},{"module_index":1,"ip":"0x7fb36dc1a71a","trust":"cfi"},{"module_index":1,"ip":"0x7fb3708d0159","trust":"cfi"},{"module_index":1,"ip":"0x7fb3709719ae","trust":"cfi"},{"module_index":1,"ip":"0x7fb37123fe16","trust":"cfi"},{"module_index":1,"ip":"0x7fb371320c70","trust":"cfi"},{"module_index":1,"ip":"0x7fb37132146f","trust":"cfi"},{"module_index":1,"ip":"0x7fb3713219eb","trust":"cfi"},{"module_index":0,"ip":"0x559446cc0832","trust":"cfi"},{"module_index":2,"ip":"0x7fb377545ca7","trust":"cfi"},{"module_index":2,"ip":"0x7fb377545d64","trust":"cfi"},{"module_index":0,"ip":"0x559446cc0430","trust":"cfi"}]}]}},"boolean":{"environment.headless_mode":false,"crash.startup":false},"quantity":{"memory.total_page_file":49981153280,"memory.available_commit":0,"memory.available_swap":10845548544,"memory.total_physical":33597157376,"memory.available_physical":6621511680,"memory.available_virtual":12481409024},"timespan":{"environment.uptime":{"value":75208523,"time_unit":"millisecond"}},"string":{"crash.app_channel":"esr","crash.minidump_sha256_hash":"f11c686dfa4c224a9c8d86e0a8f302ebb271f6872bcc0b04b6780ecfd82dc4aa","crash.app_build":"20260826142222","crash.moz_crash_reason":"MOZ_CRASH(Crash via about:crashparent)","crash.app_display_version":"140.15.0","crash.process_type":"main"}}}
{"headers":{},"body_has_info_sections":true,"ping_name":"crash","uploader_capabilities":[]}
|
|
Assignee | |
Comment 8•2 months ago
|
||
Okay, well that would have an error if it couldn't read the prefs file (however, it doesn't log anything if the prefs file doesn't exist at the path it expects, or if there's no profile directory info, so those possibilities aren't ruled out). I'll add logging for those paths, and I'll also try to reproduce what you're seeing.
|
|
Assignee | |
Comment 9•2 months ago
|
||
Unfortunately, I am unable to reproduce the behavior you are seeing in an ESR 140.15 release build. I confirmed (by increasing the log level) that the ping is disabled and discarded, as expected.
I wonder whether there is something on the client (Firefox) side that is preventing the ProfileDirectory annotation from being set. I will make a build for you with extra logging, however I fear that something specific to your current installation may be to blame (though I guess you could copy the crashreporter binary from that build into your existing installation).
|
|
Assignee | |
Comment 10•2 months ago
|
||
As far as the ProfileDirectory annotation: you should be able to check whether it's present (and correct) by finding the crash report .extra file in the ~/.mozilla/firefox/Crash Reporters/pending directory while the crash reporter client is still open.
|
Reporter | |
Comment 11•2 months ago
|
||
the .extra file located in /.mozilla/firefox/Crash Reports/pending/ contain this :
"ProfileDirectory":"/home/user/.mozilla/firefox/444xxxxxx.default-esr"
444xxxxxx.default-esr is the correct profile directory used by Firefox (I can see it just by looking to recent file date change)
and if I read the prefs.js file located in /home/user/.mozilla/firefox/444xxxxxx.default-esr/ (which recently had a date change so I'm sure Firefox use this file), I have this prefs (redacted for my privacy) :
user_pref("datareporting.dau.cachedUsageProfileGroupID", "xxxxx-xxxxxxxx");
user_pref("datareporting.dau.cachedUsageProfileID", "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx");
user_pref("datareporting.policy.dataSubmissionPolicyAcceptedVersion", 2);
user_pref("datareporting.policy.dataSubmissionPolicyNotifiedTime", "17xxxxxxxxxxxxxx");
user_pref("datareporting.usage.uploadEnabled", false);
All the mozilla telemetry ping were rejected by my firewall since several months, I wonder if that could explain my specific behaviour (especially considering this open Bug 2064353, but no deletion_request is present under my ~/.mozilla/firefox/Crash Reports/glean/ directory)
|
|
Reporter | |
Comment 12•2 months ago
|
||
I also add that when Firefox crashes, the Mozilla Crash Reporter window appear and the checkbox "Tell Mozilla about this crash so they can fix it" is unchecked but the telemetry crashes report is sent anyway when I close this window, even if I check then I uncheck this checkbox
|
|
Assignee | |
Comment 13•2 months ago
|
||
Huh. But there's no datareporting.healthreport.uploadEnabled pref there? That's the pref that we look for; if it's missing, that's definitely the problem. That's also what you said was false in the original report. Is it ending up in a different file, perhaps?
(In reply to mozilla from comment #12)
I also add that when Firefox crashes, the Mozilla Crash Reporter window appear and the checkbox "Tell Mozilla about this crash so they can fix it" is unchecked but the telemetry crashes report is sent anyway when I close this window, even if I check then I uncheck this checkbox
Do you truly mean the report is sent, regardless of the setting, or the ping? These are two different things, and pings are always sent unless telemetry is disabled. If the report is being sent, when the checkbox is unchecked, that would be a serious issue. There are extensive tests around that, so I'd be surprised if that were the case.
|
|
Assignee | |
Comment 14•2 months ago
|
||
Here's a link to a Linux try build artifact with some additional logging added to ESR 140.15: target.tar.xz. If you copy the crashreporter binary into your installation and launch firefox with MOZ_CRASHREPORTER_LOG=debug, there will be some extra info in the log file related to the telemetry enablement check.
|
|
Reporter | |
Comment 15•2 months ago
|
||
(In reply to Alex Franchuk [:afranchuk] from comment #13)
Huh. But there's no
datareporting.healthreport.uploadEnabledpref there? That's the pref that we look for; if it's missing, that's definitely the problem. That's also what you said wasfalsein the original report. Is it ending up in a different file, perhaps?
Huuuu, yeah, i didn't even notice that this pref is not present in the prefs.js file but datareporting.healthreport.uploadEnabled is present in about:config and put to false
I checked on my second computer (same debian 13 OS, same firefox esr version) and I don't have datareporting.healthreport.uploadEnabled in prefs.js either.
If I check the checkbox "Automatically send crash reports" on "Privacy & Security" Parameter, it put this pref in prefs.js :
user_pref("browser.crashReports.unsubmittedCheck.autoSubmit2", true);
but still no datareporting.healthreport.uploadEnabled present in the prefs.file
Do you truly mean the report is sent, regardless of the setting, or the ping? These are two different things, and pings are always sent unless telemetry is disabled. If the report is being sent, when the checkbox is unchecked, that would be a serious issue. There are extensive tests around that, so I'd be surprised if that were the case.
yes I meant to say the report is sent in any case (actually blocked by my firewall), regardless of the setting.
I didn't identify any ping in my firewall log.
To summarize, this is the use case :
- all telemetry is turn off in the firefox parameter page
- datareporting.healthreport.uploadEnabled is present and put to false in about:config
- datareporting.healthreport.uploadEnabled is not present in prefs.js
- about:crashparent make my firefox crash, then 2 things happens in parallel :
- the Mozilla Crash Reporter window appear and the checkbox "Tell Mozilla about this crash so they can fix it" is unchecked
- 3 crashreports separated by 5 seconds (I guess it poll 2 extra time because my firewall block it) are blocked by my firewall, even if I let the Crash Reporter window open. Bellow is the blocked command reported by my firewall :
curl --user-agent crashreporter/1.0.0 --header X-Telemetry-Agent: Glean/64.3.1 (Rust on Linux) --header Content-Type: application/json; charset=utf-8 --header Content-Encoding: gzip --header Content-Length: 1251 --header Date: Thu, 10 Sep 2026 14:40:38 GMT --data-binary @- https://incoming.telemetry.mozilla.org/submit/firefox-crashreporter/crash/1/<UUID>
I tested with all my extensions unloaded just in case.
Now, this is what I've done :
- I put user_pref("datareporting.healthreport.uploadEnabled", false); in my prefs.js when firefox is closed
- I open Firefox
- Then I open prefs.js and my user_pref("datareporting.healthreport.uploadEnabled", false) has disappeared from the file
My understanding is that datareporting.healthreport.uploadEnabled is located somewhere other than in my prefs.js file because I can see it in about config (maybe hardcoded? )
So I check all my file with this command :
grep -R 'datareporting.healthreport.uploadEnabled' ~/.mozilla/firefox//.*
but no file was found.
I checked in a 2 years old backup of my SSD just in case and I found datareporting.healthreport.uploadEnabled in the backup prefs.js file
|
|
Reporter | |
Comment 16•2 months ago
|
||
(In reply to Alex Franchuk [:afranchuk] from comment #14)
Here's a link to a Linux try build artifact with some additional logging added to ESR 140.15: target.tar.xz. If you copy the
crashreporterbinary into your installation and launch firefox withMOZ_CRASHREPORTER_LOG=debug, there will be some extra info in the log file related to the telemetry enablement check.
I tested your delivery :
- 140.16.0esr (64-bit)
- Nightly Data Collection and use turn off (unchecked) in Firefox parameters page
- user_pref("datareporting.usage.uploadEnabled", false) is present in the file prefs.js
Then ==> about:crashparent :
- the Mozilla Crash Reporter window appear and the checkbox "Tell Mozilla about this crash so they can fix it" is unchecked
- same result : 3 crashreports separated by 5 seconds (I guess it poll 2 extra time because my firewall block it) are blocked by my firewall, even if I let the Crash Reporter window open.
here is the content of /.mozilla/firefox/Crash Reports/crashreporter_settings.json
{
"submit_report": false,
"include_url": false,
"test_hardware": false
}
/.mozilla/firefox/Crash Reports/submit.log
[ERROR crashreporter::net::ping] failed to send legacy ping: failed to create telemetry crash ping: missing TelemetryClientId
|
|
Assignee | |
Comment 17•2 months ago
|
||
Sorry, but you are confused by terminology here. The traffic you are seeing is crash pings, not reports. Whether the box is checked or not, the ping is always attempted (aside from when telemetry is disabled). The retries and the curl invocation you see are crash pings being sent.
Did you run with MOZ_CRASHREPORTER_LOG=debug in the environment? The log should have had some more entries.
As to the prefs.js entry being removed, I have an idea why that might be happening: the default value for the static pref is false, and as such maybe it is removed from the file in that case (I'm not very familiar with prefs, but that sounds reasonable). If that is the case, I definitely need to make some changes to that logic. It's troublesome to have to rely on knowledge of the static pref declaration to determine the default value, but if that's how it works, then that's what we have to do.
In the non-ESR version of these patches, the pref is read in Firefox and the deletion request is sent as a maintenance task, so the setting would be respected even if the crash reporter doesn't read it correctly.
|
|
Reporter | |
Comment 18•2 months ago
|
||
(In reply to Alex Franchuk [:afranchuk] from comment #17)
Sorry, but you are confused by terminology here. The traffic you are seeing is crash pings, not reports. Whether the box is checked or not, the ping is always attempted (aside from when telemetry is disabled). The retries and the
curlinvocation you see are crash pings being sent.
Haaa, ok, that makes sense. So I guess the domain incoming.telemetry.mozilla.org is for the ping and the domain crash-reports.mozilla.com is for report. And I see only incoming.telemetry.mozilla.org
Did you run with
MOZ_CRASHREPORTER_LOG=debugin the environment? The log should have had some more entries.
This is the log of submit.log :
[INFO glean_core] Glean initialized
[INFO glean_core::upload::directory] Processing ping at: /home/user/.mozilla/firefox/Crash Reports/glean/deletion_request/eb1600a0-c464-47cb-a734-052e211a4d85
[INFO glean_core::upload] New upload task with id eb1600a0-c464-47cb-a734-052e211a4d85 (path: /submit/firefox-crashreporter/deletion-request/1/eb1600a0-c464-47cb-a734-052e211a4d85)
[INFO glean_core::metrics::ping] The ping 'crash' is disabled and will be discarded and not submitted
[ERROR crashreporter::net::ping] failed to send legacy ping: failed to create telemetry crash ping: missing TelemetryClientId
[ERROR crashreporter::glean::uploader] failed to send glean ping: process failed (exit status exit status: 6) with stderr: % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- 0:00:26 --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- 0:00:27 --:--:-- 0curl: (6) Could not resolve host: incoming.telemetry.mozilla.org
[WARN glean_core::upload] Recoverable upload failure while attempting to send ping eb1600a0-c464-47cb-a734-052e211a4d85, will retry. Error was RecoverableFailure { unused: 0 }
[INFO glean_core::upload::directory] Processing ping at: /home/user/.mozilla/firefox/Crash Reports/glean/deletion_request/eb1600a0-c464-47cb-a734-052e211a4d85
[INFO glean_core::upload] New upload task with id eb1600a0-c464-47cb-a734-052e211a4d85 (path: /submit/firefox-crashreporter/deletion-request/1/eb1600a0-c464-47cb-a734-052e211a4d85)
[ERROR crashreporter::logic] failed to send report: process failed (exit status exit status: 6) with stderr: % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- 0:00:01 --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- 0:00:25 --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- 0:00:26 --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- 0:00:27 --:--:-- 0curl: (6) Could not resolve host: crash-reports.mozilla.com
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00[INFO glean_core::database] Database initialized
Sorry for the confusion and for wasting some of your time.
I’ve now realized by readind this log that the firewall entry I was looking at was only the DNS lookup made by curl over UDP/53, not the actual transmission of the crash ping.
So I overstated the issue in my previous comments.
That said, if telemetry is completely disabled, it may still be preferable not to invoke curl at all, since doing so initiates a DNS lookup and therefore still causes observable network activity related to crash telemetry.
Thank you for taking the time to investigate this, and apologies again for the noise.
|
|
Assignee | |
Comment 19•2 months ago
|
||
Unfortunately, if telemetry is disabled, we still need to get the deletion request through. So we can't stop the network requests.
I see in the log that it does have a deletion request and the crash ping is disabled. I assume this was after you manually added the pref to prefs.js? But otherwise, I don't see the new log entries that I added in that build, which is weird. I added logs to always log something, regardless of the logic path.
|
|
Assignee | |
Comment 20•2 months ago
|
||
FYI, on my Nightly install at least, it seems like the pref is omitted if true, and it is included if false. So that runs counter to what I suspected (though ESR may behave differently, so I'll check that too).
|
|
Reporter | |
Comment 21•2 months ago
|
||
I see in the log that it does have a deletion request and the
crashping is disabled. I assume this was after you manually added the pref toprefs.js?
you're correct. I had a file created today in /.mozilla/firefox/Crash Reports/glean/deletion-request/
I remove this deletion-request file and :
0n your delivery exec 140.16.0esr (64-bit) :
this is the new log after a crash on your
File : /.mozilla/firefox/Crash Reports/submit.log)
[INFO glean_core::database] Database initialized
[INFO glean_core] Glean initialized
[INFO glean_core::upload] No more pings to upload! You are done.
[INFO glean_core::metrics::ping] The ping 'crash' is disabled and will be discarded and not submitted
[ERROR crashreporter::net::ping] failed to send legacy ping: failed to create telemetry crash ping: missing TelemetryClientId
I don't have any other logs
And I don't have any DNS traffic warning on my firewall.
On my original 140.15.0esr firefox :
the 3 DNS traffic warning still appears on my firewall after a crash despite no deletion-request file present
|
|
Assignee | |
Comment 22•2 months ago
|
||
I just installed ESR 140.15 for Linux.
The good: I see that when I disable telemetry, user_pref("datareporting.healthreport.uploadEnabled", false); appears in the prefs file, and when I re-enable it, it disappears (i.e., it behaves as if "true" is the default when absent, which is what the feature assumes). This means that, generally, other people using ESR140 do have their telemetry settings honored.
The bad: I couldn't reproduce the behavior you're seeing!
The ugly: I really can't imagine why your setup is behaving the opposite way (a missing entry indicating false rather than true). I will ask some preferences peers about it.
|
|
Assignee | |
Comment 23•2 months ago
|
||
Is the debian package you installed the one built by Mozilla, or did you get it from elsewhere?
|
|
Assignee | |
Comment 24•2 months ago
|
||
:glandium, any idea why Firefox would behave as if a different value were the default wrt the preferences file?
In short: the reporter has ESR 140.15 installed on Linux, and Firefox is only writing the datareporting.healthreport.uploadEnabled if the value is set to true. However, I installed ESR 140.15 and I see Firefox writing datareporting.healthreport.uploadEnabled if the value is set to false (and likewise, this is how Nightly behaves). To be fair, StaticPrefList.yaml lists the value as false, which sort of feels like the behavior the user is seeing makes more sense. But in that case, why is the behavior the opposite as far as I've ever seen?
I'm reaching out to you because you are the only person listed as an owner/peer for Core: Preferences. Please redirect to someone else if appropriate!
|
|
Reporter | |
Comment 25•2 months ago
|
||
(In reply to Alex Franchuk [:afranchuk] from comment #23)
Is the debian package you installed the one built by Mozilla, or did you get it from elsewhere?
That's the default firefox package on debian 13 :
apt policy firefox-esr
firefox-esr:
Installé : 140.15.0esr-1~deb13u1
candidat : 140.15.0esr-1~deb13u1
Table de version :
*** 140.15.0esr-1~deb13u1 500
500 https://security.debian.org/debian-security trixie-security/main amd64 Packages
100 /var/lib/dpkg/status
But my .mozilla/ directory is very old, I'll move it and let you know if the behavior differs
|
|
Assignee | |
Comment 26•2 months ago
•
|
||
I see a few commits downstream in that package which affect preferences, but they shouldn't cause the behavior we're seeing (unless you have some prefs in /etc/iceweasel/pref or something similar to that, see this commit?).
|
|
Reporter | |
Comment 27•2 months ago
|
||
I can confirm that with a fresh new .mozilla/ directory (meant new profile, pref, extension, etc...), this is the behaviour that I have :
with 140.15.0esr-1~deb13u1 :
-
when all telemetry is off (uncheck) :
there is no datareporting.healthreport.uploadEnabled pref in my prefs.js file
datareporting.healthreport.uploadEnabled is set to false in about : config -
when the telemetry is on (check) :
user_pref("datareporting.healthreport.uploadEnabled", true); is present in my prefs.js file
datareporting.healthreport.uploadEnabled is set to true in about : config
on your nightly build 140.16.0esr (64-bit)
-
when all telemetry is off (uncheck) :
user_pref("datareporting.healthreport.uploadEnabled", false); is present in my prefs.js file
datareporting.healthreport.uploadEnabled is set to false in about : config -
when the telemetry is on (check) :
there is no datareporting.healthreport.uploadEnabled pref in my prefs.js file
datareporting.healthreport.uploadEnabled is set to true in about : config
So yes, both exec react in the opposite way on saving pref in prefs.js file.
Maybe that explain why I can see a curl crash DNS traffic on 140.15.0esr and not in 140.16.0esr as explain in comment #21
|
|
Reporter | |
Comment 28•1 month ago
|
||
Today, Firefox 140.16.0esr (64 bits) was pushed in the debian repository and installed on my computer.
I have the same behaviour as in 140.15.0esr-1~deb13u1 :
-
when all telemetry is off (uncheck) :
there is no datareporting.healthreport.uploadEnabled pref in my prefs.js file
datareporting.healthreport.uploadEnabled is set to false in about : config -
when the telemetry is on (check) :
user_pref("datareporting.healthreport.uploadEnabled", true); is present in my prefs.js file
datareporting.healthreport.uploadEnabled is set to true in about : config
So, at this point, I can say the firefox 140.16.0esr behaviour installed from the debian repository is not equivalent as the behaviour of your nightly build 140.16.0esr.
I also temporary removed the rules blocking the curl request on my firewall and then I can see a complete ping packet on port 443 and not only on port 53. I said in Comment #18 that I thought it was only a DNS lookup from curl but it appears the ping is actually being sent to the server by curl, not just the DNS lookup.
This is also the curl command showed with my firewall on port 443 when all telemetry is off:
curl --user-agent crashreporter/1.0.0 --header Content-Encoding: gzip --header Content-Type: application/json; charset=utf-8 --header Content-Length: 1232 --header Date: Wed, 16 Sep 2026 20:59:42 GMT --header X-Telemetry-Agent: Glean/64.3.1 (Rust on Linux) --data-binary @- https://incoming.telemetry.mozilla.org/submit/firefox-crashreporter/crash/1/<UUID>
You said in comment #17 :
The traffic you are seeing is crash pings, not reports
I highly doubt that considering the --data-binary flag in the curl command is pointing to the crash file on my disk.
|
||
Comment 29•1 month ago
•
|
||
(In reply to Alex Franchuk [:afranchuk] from comment #24)
:glandium, any idea why Firefox would behave as if a different value were the default wrt the preferences file?
The debian package has a different default, thus the observed behavior. The default is set via a system preference (.js) file.
|
|
Assignee | |
Comment 30•1 month ago
|
||
(In reply to mozilla from comment #28)
I highly doubt that considering the --data-binary flag in the curl command is pointing to the crash file on my disk.
No, it is a crash ping. Crash reports do not go to incoming.telemetry.mozilla.org. What makes you think it's pointing to a crash file on your disk? It's sending the Glean crash ping, which is stored as a pending ping on disk.
|
|
Assignee | |
Comment 31•1 month ago
|
||
(In reply to Mike Hommey [:glandium] from comment #29)
(In reply to Alex Franchuk [:afranchuk] from comment #24)
:glandium, any idea why Firefox would behave as if a different value were the default wrt the preferences file?
The debian package has a different default, thus the observed behavior. The default is set via a system preference (.js) file.
Okay, that means the crash reporter client needs to be aware of that default. I didn't know that was a possibility.
|
|
Assignee | |
Comment 32•1 month ago
|
||
The default pref is set at https://salsa.debian.org/mozilla-team/firefox/-/blob/release/master/debian/browser.js.in. That seems to end up at usr/lib/firefox/browser/defaults/preferences/firefox.js, though I didn't see that in the .deb I inspected, so I'm going to re-download and check again (in case I pulled the wrong one).
|
|
Assignee | |
Comment 33•1 month ago
|
||
I found the file actually ends up at /etc/firefox-esr/firefox-esr.js. Do you see that on your system?
|
|
Assignee | |
Comment 34•1 month ago
|
||
Figuring out all the possible files that have preferences set will be a bit painful from the crashreporter client.
|
|
Reporter | |
Comment 35•1 month ago
|
||
(In reply to Alex Franchuk [:afranchuk] from comment #33)
I found the file actually ends up at
/etc/firefox-esr/firefox-esr.js. Do you see that on your system?
yes, i can see this file /etc/firefox-esr/firefox-esr.js on my Debian system with inside :
pref("datareporting.healthreport.uploadEnabled", false);
|
|
Reporter | |
Comment 36•1 month ago
|
||
(In reply to Alex Franchuk [:afranchuk] from comment #30)
(In reply to mozilla from comment #28)
I highly doubt that considering the --data-binary flag in the curl command is pointing to the crash file on my disk.
No, it is a crash ping. Crash reports do not go to
incoming.telemetry.mozilla.org. What makes you think it's pointing to a crash file on your disk? It's sending the Glean crash ping, which is stored as a pending ping on disk.
Because I would expect the ping to be just a short keep-alive or status message, not a full binary crash report encoded as JSON containing information such as the client ID, memory usage, module, library and other crash-related data.
I can also confirm that the data passed through --data-binary @- in the curl command is the gz content of the corresponding file located in ~/.mozilla/firefox/Crash Reports/glean/pending_pings/<UUID>.
|
|
Assignee | |
Comment 37•1 month ago
|
||
The binary part is because it is compressed. A crash ping contains non-personally-identifiable information relevant to crashes. It is not a status message. "Ping" is used because it takes the form of a telemetry ping. In contrast, a report may contain personally-identifiable information (since it may include a minidump of the crash).
|
|
Reporter | |
Comment 38•1 month ago
|
||
I see. The crash reports in my pending directory are indeed much more verbose than the “ping”. That said, I think users may still be concerned to learn that the ping includes information such as the client_id, OS, and first_run_date, particularly when telemetry has been disabled, as these fields may still contribute to identifying or correlating a client over time.
|
|
Assignee | |
Comment 39•1 month ago
|
||
Yes, this needs to be fixed! Pings shouldn't be sent when telemetry is disabled.
|
|
Assignee | |
Comment 40•1 month ago
|
||
I'm reducing the severity because this is an atypical setup (relatively speaking, across all of our platforms), however this is still a high priority to fix.
There is also a manual workaround: move the pref to the expected prefs.js file (modifying the profile and the system prefs files).
|
|
Assignee | |
Comment 41•1 month ago
|
||
This fixes cases, like that described in the bug, where a pref that
changes the crashreporter client's behavior wasn't being read properly.
This introduces a number of changes to make prefs handling more
organized. In particular, the Prefs type will look for a set of prefs
relevant to the program and aggregate values as prefs files are loaded.
This consolidates code from the langpack and glean modules into the
prefs module.
The mocked_static! macro was modified in a minor way to explicitly
indicate the mocked value. This is used in a new flatpak detection
static. A few other minor changes to the mock interface were made to
accommodate the new tests.
|
|
Assignee | |
Comment 42•29 days ago
|
||
This removes the unnecessary (and now duplicated) prefs_parser module.
|
||
Updated•29 days ago
|
|
|
Assignee | |
Comment 43•29 days ago
|
||
|
|
Assignee | |
Comment 44•29 days ago
|
||
Prefs files are read in prefs directories in reverse-alphabetical order.
The order of directories here matches the order in which Firefox loads
them.
This adds support to the prefs parser for other prefs "functions". User
pref files are supposed to only have user_pref, but default pref files
can have the others.
|
|
Assignee | |
Comment 45•29 days ago
|
||
This fixes the case described in the bug.
The mocked_static! macro was modified in a minor way to explicitly
indicate the mocked value. This is used in the flatpak detection static
value.
|
|
||
Updated•26 days ago
|
|
|
||
Updated•26 days ago
|
|
|
||
Updated•26 days ago
|
|
|
||
Updated•26 days ago
|
|
|
||
Updated•26 days ago
|
|
||
Comment 46•19 days ago
|
||
|
||
Comment 47•19 days ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/ea9bdc8a4dd3
https://hg.mozilla.org/mozilla-central/rev/39522905c0ab
https://hg.mozilla.org/mozilla-central/rev/df514fec09d3
https://hg.mozilla.org/mozilla-central/rev/2ab31f6f7922
|
|
Assignee | |
Comment 48•18 days ago
|
||
This is a partial change taken from
https://phabricator.services.mozilla.com/D323814 to enable uplift.
|
|
||
Updated•18 days ago
|
|
|
Assignee | |
Comment 49•18 days ago
|
||
This replaces the prefs_parser module.
The Prefs type will look for a set of prefs relevant to the program
and aggregate values as prefs files are loaded. This consolidates code
from the langpack and glean modules. It is intended to be
functionally equivalent to the existing prefs loading. Improvements are
in following patches.
Original Revision: https://phabricator.services.mozilla.com/D333401
|
|
||
Updated•18 days ago
|
|
|
Assignee | |
Comment 50•18 days ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D334738
|
|
||
Updated•18 days ago
|
|
|
Assignee | |
Comment 51•18 days ago
|
||
Prefs files are read in prefs directories in reverse-alphabetical order.
The order of directories here matches the order in which Firefox loads
them.
This adds support to the prefs parser for other prefs "functions". User
pref files are supposed to only have user_pref, but default pref files
can have the others.
Original Revision: https://phabricator.services.mozilla.com/D334739
|
|
||
Updated•18 days ago
|
|
|
Assignee | |
Comment 52•18 days ago
|
||
This fixes the case described in the bug.
The mocked_static! macro was modified in a minor way to explicitly
indicate the mocked value. This is used in the flatpak detection static
value.
Original Revision: https://phabricator.services.mozilla.com/D334741
|
|
||
Updated•18 days ago
|
|
|
||
Comment 53•18 days ago
|
||
firefox-esr153 Uplift Approval Request
- User impact if declined/Reason for urgency: Users who have telemetry disabled in system prefs files will still have crash ping telemetry sent.
- Code covered by automated testing?: yes
- Fix verified in Nightly?: yes
- Needs manual QE testing?: no
- Steps to reproduce for manual QE testing:
- Risk associated with taking this patch: medium
- Explanation of risk level: This is a large set of changes, so it is inherently more risky. It also required some alterations to make it work with ESR: there were conflicts because ESR doesn't have the patches from https://bugzilla.mozilla.org/show_bug.cgi?id=2069364. However, there are many unit tests that still pass with the altered patches.
- String changes made/needed?: None
- Is Android affected?: no
|
|
Assignee | |
Comment 54•18 days ago
•
|
||
FYI: the problem with the Debian packaging is fixed and I am uplifting the changes to ESR153. We will not be uplifting to ESR140: it is no longer supported. If you can change to the Debian stable-security channel, that uses ESR153 (and will eventually get these fixes once the uplift lands in a new minor ESR version and Debian takes that release).
In the meantime, a workaround you can use is to copy the datareporting.healthreport.uploadEnabled pref from /etc/firefox-esr/firefox-esr.js to your profile's prefs.js and comment out or remove the setting in the original file. You should do this when no Firefox instances are open to avoid the prefs file(s) being overwritten.
|
||
Updated•17 days ago
|
|
||
Updated•12 days ago
|
|
|
||
Updated•8 days ago
|
|
|
||
Updated•8 days ago
|
|
|
||
Updated•8 days ago
|
|
|
||
Updated•8 days ago
|
|
|
||
Updated•8 days ago
|
|
||
Updated•8 days ago
|
|
|
||
Comment 55•8 days ago
|
||
| uplift | ||
|
||
Updated•5 days ago
|
Description
•