As a follow up to the first step in the WDBA project, we'll be implementing notifications for Win 10 users who have switched their default browser from Firefox to Edge.

Requirements

• Follows designs specified here, which were created from 1607833.
• Implements notifications following MSFT's toast notification guidelines.
• Notifications are displayed following this logic:
  - [first notification] If we detect that a user’s previous default was Firefox, and now it’s Edge, we show the first notification. If this has been shown once, never show it again.
  - [second notification] If the user clicked “remind me later” in the first notification, we’ll show the second notification after 7 days. We’ll only show this notification if the users’ default is Edge. If this has been shown once, never show it again.
• Includes telemetry, specifically:
  1. which notification is shown (we have two)
  2. which action was taken (clicked primary button, clicked secondary button, clicked dismiss icon)

:mreid - We met yesterday with Ryan Harter from Data Science about using either a document id, or a client id that's separate from the actual profile's client id. The concern here is that we may not be able to de-dupe clients who send a lot of pings. Do you think this is something that we should try to address for this phase of this project?

From bug 1621703, it sounds like the instrumentation will be done using Glean, so I'll redirect to Mike on whether we need to do anything novel for handling duplicate submissions.

If using Glean (keeping in mind that Glean in Windows won't be available until at least 2021Q1), this wouldn't be a problem to generate client ids that are different from the standard client id and use that for deduplication for each client.

I doubt it would be a problem even if using the existing legacy telemetry system, but I think :chutten could better speak to that.

(In reply to Michael Droettboom [:mdroettboom] from comment #3)

If using Glean (keeping in mind that Glean in Windows won't be available until at least 2021Q1)

Ah, very good to know. That would mean that we won't be using it here, since we're planning to ship this in Q2 2020.

From the sounds of things none of Telemetry's docid or client_id machinery is likely to be available to the agent since it's outside of Firefox. We could do what we're doing for the dataupload pref (throw it over the wall using the registry) but that only gets you the client_id that was most recently used in the most recently-used Firefox profile, not anything that'll clue you in to resets, deletion-requests, or how to generate your own.

A mechanism for weighting and identifying chatty vs quiet clients seems like a good thing to have. I recommend having your own identifier that rotates regularly (maybe every 28 days/pings?) coupled with a sequence number.

Based on the lack of API support, we're removing l10n from the initial release here and will be showing the notification for users with both a system and browser local of English only.

@Pike - I'm not sure how I ought to limit to English Firefox and how to prevent localizers from making unnecessary translations. Could you point me in the right direction here? I'd like to leave in as much of the l10n handling as possible to make it easy to flip on if we solve the necessary problems.

I guess the right way to do this would be to put the ini file outside of locales/en-US, and to move the build logic away from toolkit/locales/moz.build and LOCALIZED_GENERATED_FILES to something and GENERATED_FILES.

I'd also like to get a better understanding of the role of toolkit and browser here, and platforms, so that might be also good to do in a follow-up.

Should we re-use bug 1621700 for that at a later point? Probably regardless of the Fluent conversation in that bug.

@Pike - That sounds like a good solution for preventing unnecessary translations but, unless I'm mistaken, it will not limit execution to English Firefox; everyone would just see English text, regardless of their locale. Is there a good way of addressing that issue?

I'm not sure what you are asking about toolkit, browser, and platforms. Perhaps you could rephrase the question?

Oh, I thought you had that figured out, misread your comment. Really depends on how you start your feature. There's nothing on the packaging side, I think.

If you can get to the locale service, relatively late, and check https://searchfox.org/mozilla-central/source/intl/locale/mozILocaleService.idl#145 to be en-US, you can enable your feature. Caveat, during startup, Firefox might go through a phase with en-US, and then reconsider, for example when language packs kick in. https://firefox-source-docs.mozilla.org/intl/locale_startup.html has details.

Re browser/toolkit: Thunderbird and SeaMonkey both go through toolkit/locales/moz.build. So if you put the LOCALIZED_GENERATED_FILES in toolkit, they will create those files. They might not package them, but still.

Re platforms, I'd like to make sure that as much of the l10n repacks is platform agnostic, and that platform dependencies kick in in packaging, if at all. That'll allow for some cost-cutting optimizations in the repack automation.

I don't think I can get the locale service outside of Firefox. Any other options?

I think reusing bug 1621700 for the browser/toolkit/platforms changes sounds fine.

Discussed on Slack.

This feature is no longer confidential.