Open Bug 1726444 Opened 3 years ago Updated 4 months ago

TB tries to ping telemetry even if set offline


(Toolkit :: Telemetry, defect, P3)

Windows 10





(Reporter: buecher, Unassigned)


TB 91 is set to offline.
In error console, I see multiple unsuccessfull attempts of telemetry to ping somewhere.

Not knowing what telemetry tries to do there, that still feels counter-intuitive if TB is set to offline.


Component: Untriaged → General
Ever confirmed: false
Flags: needinfo?(mkmelin+mozilla)

I don't think Thunderbird per se it responsible for the sending. It's all in (shared code) at

Can you reproduce with Firefox?
Probably a check should be added somewhere

Flags: needinfo?(mkmelin+mozilla)

klaus ...

Can you reproduce with Firefox?
Probably a check should be added somewhere

Flags: needinfo?(buecher)
Whiteboard: [closeme 2021-09-25]
Blocks: tb91found


No longer blocks: tb91found
Component: General → Telemetry
Product: Thunderbird → Toolkit
Version: Thunderbird 91 → unspecified

The best place for this sort of check looks like it would be sendingEnabled... but it looks like if we put it there, then we will never retry sending that ping and simply archive it for all time.

Next most likely looks like the property canSendNow... however, it appears to be most interested in describing whether Firefox is physically able to send now and will happily ask pingsender to try... which I gather isn't the desired outcome.

Next from there is to interject ourselves in submitPing. As new pings come by and try to be sent we can decide to save them as pending pings (so they'll be retried later) and then bail out in much the way that canSendNow presently works. We'll just have to do that earlier than the pingsender check (but below the sendingEnabled check. If we're both offline and the user's disabled the Telemetry pref, we still want to drop the ping on the floor after all.). It's not a quick stop, though, as any pending or current pings in the scheduler will remain there, and if the scheduler ticks (like after a timer due to throttling, or near local midnight) they'll try to be sent again. But persisting the current pings down to pending pings or pausing the tick would just be a pain. If we're that worried, a second check in _doSendTask or nearby will handle it... but that level of complexity is asking for bugs.

Yes, that seems most appropriate. Somewhere around here we could have an early return and a nice comment. And a nice test or four in toolkit/components/telemetry/tests/unit possibly in test_TelemetrySend.js.

Severity: -- → S4
Ever confirmed: true
Priority: -- → P3

Resolved per whiteboard

Closed: 2 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2021-09-25]

this is still happening in 115. It is totally annoying when developing, because suddenly error console is flooded by red telemetry error messages, happening often

Flags: needinfo?(buecher)
Resolution: INCOMPLETE → ---
You need to log in before you can comment on or make changes to this bug.