Closed Bug 1615981 Opened 4 years ago Closed 4 years ago

[Thunderbird Telemetry] collect number of accounts + types

Categories

(Thunderbird :: General, task)

task
Not set
normal

Tracking

(thunderbird78+ fixed)

RESOLVED FIXED
Thunderbird 79.0
Tracking Status
thunderbird78 + fixed

People

(Reporter: mkmelin, Assigned: rnons)

References

Details

Attachments

(1 file, 6 obsolete files)

It would be useful for getting a basic understanding of the standard setups people have to know how many accounts they have and the type of those accounts.

For chat, we could do im+protocol as a type.

Assignee: nobody → remotenonsense
Attached patch 1615981.patch (obsolete) — Splinter Review

This patch reports account types every time Thunderbird starts. For im accounts, use im_protocol as
histogram bucket label. Also added a mochitest.

Attachment #9150670 - Flags: review?(mkmelin+mozilla)

If in msgMail3PaneWindow.js I write

#ifndef MOZ_SUITE
  setTimeout(reportAccountTypes, 0);
#endif

Tests stuck and failed after a few minutes. Don't know why.

Attached patch 1615981.patch (obsolete) — Splinter Review

Learned about AppConstants, use

  if (!AppConstants.MOZ_SUITE) {
    setTimeout(reportAccountTypes, 0);
  }
Attachment #9150670 - Attachment is obsolete: true
Attachment #9150670 - Flags: review?(mkmelin+mozilla)
Attachment #9150675 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9150675 [details] [diff] [review]
1615981.patch

Review of attachment 9150675 [details] [diff] [review]:
-----------------------------------------------------------------

Maybe name it browser_accountTelemetry.js

::: mail/base/content/msgMail3PaneWindow.js
@@ +790,5 @@
>    } else {
>      window.setTimeout(loadStartFolder, 0, startFolderURI);
>    }
> +
> +  if (!AppConstants.MOZ_SUITE) {

All the things in mail/ are Thunderbird only, so this is not necessary.

Things in mailnews/ are shared.
Things in suite/ are Seamonkey only.

@@ +801,5 @@
> + * histogram bucket label.
> + */
> +function reportAccountTypes() {
> +  let histogram = Services.telemetry.getHistogramById("TB_ACCOUNT_TYPE");
> +  MailServices.accounts.accounts.forEach(a => {

for .. of is a bit more performant: 

for (let account of MailServices.accounts.accounts)

::: mail/components/telemetry/Histograms.json
@@ +26,5 @@
> +      "nntp",
> +      "exchange",
> +      "rss",
> +      "none",
> +      "im_facebook",

Hmm, I don't know what we want to do with these no longer working types: facebook, skype, yahoo at least. And twitter is also permanently broken.
We probably want to fiter them out from ever being sent out.

::: mail/test/browser/account/browser_telemetry.js
@@ +94,5 @@
> +    snapshot.values[ACCOUNT_TYPE_LABELS.indexOf("rss")],
> +    NUM_RSS,
> +    "RSS account number must be correct"
> +  );
> +

would be good to add test cases for im types too, especially as that does some extra work
Attachment #9150675 - Flags: review?(mkmelin+mozilla)
Status: NEW → ASSIGNED

Hmm, I don't know what we want to do with these no longer working types:
facebook, skype, yahoo at least. And twitter is also permanently broken.
We probably want to fiter them out from ever being sent out.

Please do not do that -- we want to know if anyone is left using them so we can remove the code eventually.

It might make sense to report instant messaging accounts as a different metric for what it's worth. Isn't a huge deal though, should be easy enough to filter after the fact if we wanted.

(In reply to Patrick Cloke [:clokep] from comment #5)

Please do not do that -- we want to know if anyone is left using them so we can remove the code eventually.

Well they aren't working at all are they? With zero chance of coming back (potentially twitter).

(In reply to Magnus Melin [:mkmelin] from comment #6)

(In reply to Patrick Cloke [:clokep] from comment #5)

Please do not do that -- we want to know if anyone is left using them so we can remove the code eventually.

Well they aren't working at all are they? With zero chance of coming back.

Right, but we still have code that gives a message saying "Hey, this isn't working, remove the account". It'd be nice to get rid of that eventually. Besides I'd just recommend doing any filtering like that server side anyway.

Is there a reason we don't simply remove such accounts in a migration? It's gotta be many major versions since those worked.

Flags: needinfo?(clokep)

Just knowing how many feed (type="rss") accounts there are is only moderately interesting. Each feed subscription is effectively a 'server', equivalent to 1 newsgroup in an nntp account or 1 email account. It would be more useful to know how many subscriptions there are per account, and how many folders per feed account, given that a folder may contain 0, 1, or many subscriptions ('servers').

True, but I think that should be another item to collect separately. It doesn't really fit the data model in here.

Attached patch 1615981.patch (obsolete) — Splinter Review

Fixed review comments except the not working im types. Will wait for further confirmation.

Attachment #9150675 - Attachment is obsolete: true
Attached patch 1615981.patch (obsolete) — Splinter Review

Forgot to add browser_accountTelemetry.js

Attachment #9151379 - Attachment is obsolete: true

(In reply to Magnus Melin [:mkmelin] from comment #8)

Is there a reason we don't simply remove such accounts in a migration? It's gotta be many major versions since those worked.

Yes, because we have no idea how many people are using those accounts. :) Regardless, that's a separate bug than this. (And so close to the next ESR I don't know why we'd remove them right now.)

The short version from my POV is: don't add more code to handle these accounts separately, just report all the IM accounts.

Flags: needinfo?(clokep)

I still don't understand what you mean. We know how many people are using them: 0. They do not work, since many years. They can not use them. People can (and will) of course have the old account listed, but the account would not be able to do anything.

Anyway, let's ignore that in this bug. I've filed bug 1641763.

Attachment #9151391 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9151391 [details] [diff] [review]
1615981.patch

Review of attachment 9151391 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thx! r=mkmelin
Attachment #9151391 - Flags: review?(mkmelin+mozilla) → review+
Target Milestone: --- → Thunderbird 79.0

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/a378b70d4431
Add telemetry to count account types. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/cf52a9080e3f
follow-up - Fix naming conflict that caused browser_tree.js to time out. rs=bustage-fix

I'm not sure if what I've just landed will also fix this failure that appeared on some Windows and Mac runs. I doubt it.

IMAP account number must be correct - "undefined" == 3 - JS frame :: chrome://mochitests/content/browser/comm/mail/test/browser/account/browser_accountTelemetry.js :: test_account_types :: line 103
RSS account number must be correct - "undefined" == 1 - JS frame :: chrome://mochitests/content/browser/comm/mail/test/browser/account/browser_accountTelemetry.js :: test_account_types :: line 108
IRC account number must be correct - "undefined" == 1 - JS frame :: chrome://mochitests/content/browser/comm/mail/test/browser/account/browser_accountTelemetry.js :: test_account_types :: line 113

:darktrojan I think I need to rework on this bug. The landed patch used histogram.add, which I guess will accumulate account numbers after restarting TB. There doesn't seem to be a histogram.set api, so I need to use scalar probe instead.

Please comment out or remove browser_accountTelemetry.js so that Treeherder can turn green, thanks.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

I'll land a backout.

Backout by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/446a471a963d
Backed out 2 changesets by request.
Attached patch 1615981.patch (obsolete) — Splinter Review

Changed to use keyed scalar probe instead of histogram probe.

Tests seem to pass on my Mac machine, will push to Try maybe tomorrow.

Attachment #9151391 - Attachment is obsolete: true
Attachment #9153812 - Flags: review?(mkmelin+mozilla)
Attached patch 1615981.patch (obsolete) — Splinter Review

Lint.

Attachment #9153812 - Attachment is obsolete: true
Attachment #9153812 - Flags: review?(mkmelin+mozilla)
Attachment #9154069 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9154069 [details] [diff] [review]
1615981.patch

Review of attachment 9154069 [details] [diff] [review]:
-----------------------------------------------------------------

Needs linting. (run ../mach eslint --fix mail/test/browser/account/browser_accountTelemetry.js )

::: mail/base/content/msgMail3PaneWindow.js
@@ +814,5 @@
> +    im_odnoklassniki: 0,
> +    im_xmpp: 0,
> +  };
> +  for (let account of MailServices.accounts.accounts) {
> +    let { type } = account.incomingServer;

we typically use the below instead:

let type = account.incomingServer.type
Attachment #9154069 - Flags: review?(mkmelin+mozilla) → feedback+
Attached patch 1615981.patchSplinter Review

Thanks, lint was done in comment 23, I didn't trigger a new Try run.

Changed to let type = account.incomingServer.type.

Attachment #9154069 - Attachment is obsolete: true
Attachment #9154835 - Flags: review?(mkmelin+mozilla)
Comment on attachment 9154835 [details] [diff] [review]
1615981.patch

Review of attachment 9154835 [details] [diff] [review]:
-----------------------------------------------------------------

r=mkmelin
Attachment #9154835 - Flags: review?(mkmelin+mozilla) → review+

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/49cb9cd70a75
follow-up - Use scalar probe to collect account numbers and types. r=mkmelin

Status: REOPENED → RESOLVED
Closed: 4 years ago4 years ago
Resolution: --- → FIXED
Comment on attachment 9154835 [details] [diff] [review]
1615981.patch

Telemetry addition - not risky.
Attachment #9154835 - Flags: approval-comm-beta?
Comment on attachment 9154835 [details] [diff] [review]
1615981.patch

Approved for beta
Attachment #9154835 - Flags: approval-comm-beta? → approval-comm-beta+
See Also: → 1702035
Blocks: 1726758
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: