1749155 - Add an option to make update available notifications badge-only

Status: RESOLVED FIXED

(Toolkit :: Application Update, enhancement)

Description

[Shane Hughes [:aminomancer]]

I'm proposing a new user preference that disables popupnotifications for certain AppMenuNotifications created by UpdateListener.jsm.

Nightly users presumably want to run the latest version of Firefox but sometimes may not want to be disturbed by update notifications. I tend to update Firefox every other day, and I prefer to disable the popupnotification that prompts me to download/install an update (depending on whether app.update.auto is enabled), since the badge icon is sufficient for my needs. I'm especially motivated to do this because, unlike many other popups, the popupnotification can't be dismissed without explicitly activating the dismiss button.

A year or two ago I published an autoconfig script designed to turn all update notifications into badge-only notifications. Which means when UpdateListener.jsm detects an update, instead of making a popupnotification, it just adds a banner item to the app menu and a badge icon to the app menu button. I made about 70 autoconfig scripts concerned with UI changes, hotkeys, etc., (mainly used by people in the firefox user stylesheet customization community, like on r/FirefoxCSS) but that update notification script is still the most popular one I made. So I think enough users care.

This proposal is for a more moderate implementation of that change — to add a new pref app.update.popupnotifications and use that pref's value as the value for dismissed for the update-available notification, and potentially for update-restart as well. The update-downloading notification is already dismissed by default so that wouldn't change. I'm thinking update-manual and update-unsupported are more urgent since they pertain to error states, so they should keep their popupnotifications.

I'll first submit a patch for just UpdateListener.jsm and firefox.js, since I haven't edited AboutPreferences before and I'm unsure whether this is worth adding to the settings UI. And maybe that should be a separate bug, so lmk what you think. 🙏

Comment 1

[Shane Hughes [:aminomancer]]

Attachment: Bug 1749155 - Add a Nightly-only option to suppress update available notifications. r?Gijs

Comment 2

[Robin Steuber (they/them) [:bytesized]]

I'm going to talk this over with my team. Excluding the about:preferences UI changes, I think that we are probably interested in this patch. We might be interested in having the about:preferences changes on Nightly, but probably not on Release. I'll let you know once we've had a chance to talk it over.

Comment 3

[Robin Steuber (they/them) [:bytesized]]

We talked about this at our team meeting today. These are the conclusions that we reached:

• We are interested in taking this for Nightly, but we want to see how it looks on Nightly for a while before we consider it for other channels. That is to say, even setting the pref manually on other channels would be disabled, at least for now.
• We want telemetry to be added. Probably we want it to be sent with this other telemetry here and here.
• We still need to get Romain's signoff on this. He's usually quite busy, but I'm going to try talking to him on Slack and see if he'll approve it.

Comment 4

[Shane Hughes [:aminomancer]]

Cool thanks for the update, I'll work on the revision restricting the feature to nightly builds and adding telemetry. I'm unsure about adding pings in both places, because I think it means there would be twice as much data from users who have auto update enabled as from users who have it disabled? And this feature is likely more desirable for users who update manually but just want badges/banners rather than doorhangers. I think the main workaround (aside from adding telemetry to AppUpdater.jsm) is if I were to add the ping at the very top of _checkForBackgroundUpdates, if (this.manualUpdateOnly) ... before it returns, but I'm not sure if that would run afoul of bug 1599590

Edit: Is our goal to record and compare how often a user downloads an update with the pref enabled, how often they install an update with the pref enabled, and how often they do so with the pref disabled, to see whether the pref has a negative impact on users' update habits? I suppose it could also be set up to record the current firefox version to determine whether users of the pref are systematically falling behind on updates. I'm not sure I'm the best person to set that up though, I don't know all the ins and outs of telemetry.

I ended up following the histogram format used elsewhere in UpdateService.jsm since I don't fully understand the external/notify/subsequent schema. So I believe it's submitting on every update flow when the user has the pref set to false on a compatible platform & build.

Comment 5

[Robin Steuber (they/them) [:bytesized]]

Ok, we've gotten the go ahead on this, as it has been described in Comment 3 (though I haven't yet figured out the exact places where we will want the telemetry to be gathered). I'm not going to have time to review the code this week, but I'll try to get to it first thing next week.

Unfortunately, I do think that it is quite likely that this patch will only ever live on Nightly. I am quite interested in reducing the frequency at which these prompts are shown on other channels. But we are very reluctant to implement features that will significantly decrease the speed at which users install updates, which this feature is likely to do. To make a long story short, there are other efforts we are working on to try to address this.

(In reply to Shane Hughes [:aminomancer] from comment #4)

I'm unsure about adding pings in both places, because I think it means there would be twice as much data from users who have auto update enabled as from users who have it disabled?

This typically isn't an issue because we have ways of de-duplicating telemetry from the same user. But I'll look into it further to determine exactly where we want the telemetry to be collected.

Edit: Is our goal to record and compare how often a user downloads an update with the pref enabled, how often they install an update with the pref enabled, and how often they do so with the pref disabled, to see whether the pref has a negative impact on users' update habits? I suppose it could also be set up to record the current firefox version to determine whether users of the pref are systematically falling behind on updates. I'm not sure I'm the best person to set that up though, I don't know all the ins and outs of telemetry.

I'm don't do much telemetry analysis, but I'll give my best estimate of how the telemetry would be used. We would want to see if it correlates with update failures. We will also probably want to see how long it takes people with and without this pref enabled to update. I'm wary of that last analysis, because unless we do an actual randomized experiment, this feature will most likely be enabled by the people that weren't going to update as frequently anyways.

I ended up following the histogram format used elsewhere in UpdateService.jsm since I don't fully understand the external/notify/subsequent schema.

Hmm, I'll have to think about this. Modern telemetry typically uses Scalars instead of Histograms. But we do occasionally add Histograms when we want them to align nicely with the existing updater telemetry.

Comment 6

[Shane Hughes [:aminomancer]]

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #5)

Ok, we've gotten the go ahead on this, as it has been described in Comment 3 (though I haven't yet figured out the exact places where we will want the telemetry to be gathered). I'm not going to have time to review the code this week, but I'll try to get to it first thing next week.

Sounds good.

Unfortunately, I do think that it is quite likely that this patch will only ever live on Nightly. I am quite interested in reducing the frequency at which these prompts are shown on other channels. But we are very reluctant to implement features that will significantly decrease the speed at which users install updates, which this feature is likely to do. To make a long story short, there are other efforts we are working on to try to address this.

That sounds ideal to me. I only ever considered this enhancement necessary for Nightly, it was just a high priority for me since I'm on Nightly for regular daily use. Release and Beta users probably don't receive enough update notifications for it to be a common concern. One issue I think would be worth looking into on all builds is interaction with the doorhangers. I understand that the Escape key's normal behavior is suppressed there to avoid a situation where pressing Escape once closes multiple doorhangers. Hopefully we can find a better solution for that than disabling the interaction altogether, since I think the doorhangers are made more annoying by the need to aim and click the buttons. When I get some more free time I'll definitely file a bug for that, though.

Hmm, I'll have to think about this. Modern telemetry typically uses Scalars instead of Histograms. But we do occasionally add Histograms when we want them to align nicely with the existing updater telemetry.

I thought a scalar might be more fitting for this type of data so I did a bit of searching for analogies, but I can't figure out this particular set of probes or why they are histograms. They were updated in 2020 and there are 3 versions of each, so I figured it must be for good reason. But anyway I'll look forward to reading the rest of your feedback.

Comment 7

[Robin Steuber (they/them) [:bytesized]]

Attachment: Bug 1749155 data review.md

Comment 8

[Chris H-C :chutten]

Comment on attachment 9260758 [details]
Bug 1749155 data review.md

Sorry for the delay!

DATA COLLECTION REVIEW RESPONSE:

Is there or will there be documentation that describes the schema for the ultimate data set available publicly, complete and accurate?

Yes.

Is there a control mechanism that allows the user to turn the data collection on and off?

Yes. This collection is Telemetry so can be controlled through Firefox's Preferences.

If the request is for permanent data collection, is there someone who will monitor the data over time?

Yes, Kirk Steuber is responsible.

Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under?

Category 2, Interaction.

Is the data collection request for default-on or default-off?

Default on for pre-release channels only.

Does the instrumentation include the addition of any new identifiers?

No.

Is the data collection covered by the existing Firefox privacy notice?

Yes.

Does the data collection use a third-party collection tool?

No.

---

Result: datareview+

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/abee0c20288f
Add a Nightly-only option to suppress update available notifications. r=fluent-reviewers,bytesized

Comment 10

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/abee0c20288f

Comment 11

[Pascal Chevrel:pascalc]

Kirk, should we mention that in our nightly release notes? (https://www.mozilla.org/en-US/firefox/98.0a1/releasenotes/) Thanks

Comment 12

[Robin Steuber (they/them) [:bytesized]]

(In reply to Pascal Chevrel:pascalc from comment #11)

Kirk, should we mention that in our nightly release notes? (https://www.mozilla.org/en-US/firefox/98.0a1/releasenotes/) Thanks

Oh, that might be good. I can't remember, is there some flag that I need to set for that? Maybe the wording could look something like:

---

New Nightly-only setting: "Show fewer update notification prompts". When the setting is enabled and Nightly is ready to restart to install updates, it will show a notification in the hamburger menu but not a popup notification. Additionally, if the user also has the "Check for updates but let you choose to install them" setting enabled, the "Update Available" notification will be shown in the hamburger menu but the popup notification will be suppressed for up to a week after the last successful update.

---

Does that sound alright? Is it too wordy?

Comment 13

[Pascal Chevrel:pascalc]

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #12)

(In reply to Pascal Chevrel:pascalc from comment #11)

Kirk, should we mention that in our nightly release notes? (https://www.mozilla.org/en-US/firefox/98.0a1/releasenotes/) Thanks

Oh, that might be good. I can't remember, is there some flag that I need to set for that? Maybe the wording could look something like:

---

New Nightly-only setting: "Show fewer update notification prompts". When the setting is enabled and Nightly is ready to restart to install updates, it will show a notification in the hamburger menu but not a popup notification. Additionally, if the user also has the "Check for updates but let you choose to install them" setting enabled, the "Update Available" notification will be shown in the hamburger menu but the popup notification will be suppressed for up to a week after the last successful update.

---

Does that sound alright? Is it too wordy?

There is a flag yes: https://wiki.mozilla.org/Release_Management/Release_Notes#Nomination_in_Bugzilla

It's perhaps a bit wordy but I prefer a wordy note than no note ;)

Comment 14

[Robin Steuber (they/them) [:bytesized]]

Release Note Request (optional, but appreciated)
[Why is this notable]:

New setting added to about:preferences. In my time working here, this sort of setting has been requested a number of times, so it seems likely that there will be interest in it.

[Affects Firefox for Android]:

No. In fact, this affects strictly Nightly. This feature will likely never be available on Beta or Release (in its current form).

[Suggested wording]:

New Nightly-only setting: "Show fewer update notification prompts". When the setting is enabled and Nightly is ready to restart to install updates, it will show a notification in the hamburger menu but not a popup notification. Additionally, if the user also has the "Check for updates but let you choose to install them" setting enabled, the "Update Available" notification will be shown in the hamburger menu but the popup notification will be suppressed for up to a week after the last successful update.

[Links (documentation, blog post, etc)]:

N/A

Comment 15

[Pascal Chevrel:pascalc]

Note added to https://www.mozilla.org/en-US/firefox/98.0a1/releasenotes/