1599138 - Add preference for disabling notifications of software updates (e.g. What's New Panel)

Status: VERIFIED FIXED

(Firefox :: Messaging System, enhancement, P1)

Description

[Aaron Benson]

Need UX for a preference to disable messaging around product updates in both Firefox Preferences and potentially w/in the What's New Panel itself.

Comment 2

[Jesper Hansen]

I found browser.messaging-system.whatsNewPanel.enabled from an article. Is this only temporary?

Comment 3

[Stephan Sokolow]

(In reply to Jesper Hansen from comment #2)

I found browser.messaging-system.whatsNewPanel.enabled from an article. Is this only temporary?

I'm not sure, but you could try setting it to false in user.js and see if that gets applied at the right point in the startup process to make it effectively permanent, even if things keep trying to reset it. That's what I'm testing out.

Comment 7

[sworddragon2]

Since bug #1607879 got marked as a duplicate of this ticket it involves a few questions:

• We already have the setting browser.messaging-system.whatsNewPanel.enabled which "should" fulfill the requirements of this ticket, except the setting is not supposed to disable the "What's New" gift entries, which would lead to some other questions:
  1. The name browser.messaging-system.whatsNewPanel.enabled implies it targets the related panel with a master switch for simple enabling/disabling.
  2. Setting this setting to false does disable the gift icon immediately without a restart which is not unexpected.
  3. The gift icon never appeared for me all the weeks/few months I had this setting enabled giving a weak evidence it does what we think it does.

How is this behavior being explained? Is browser.messaging-system.whatsNewPanel.enabled the setting to disable permanently the "What's New" gift icon and menu entry? If not, what is its purpose and is there an actual setting to disable the gift entries in current Firefox releases? If not, we have to indeed wait via this ticket until at least a setting in about:config gets implemented (or a simplified UI) to disable the gift entries.

Comment 8

[sworddragon2]

Edit: A bit correction to iii. as it would be less confusing as "The gift icon never appeared for me all the weeks/few months I had this setting set to false before updating to Firefox version 72 giving a weak evidence it does what we think it does.".

Comment 9

[u497238]

My bias against mandatory notification is that if you have 3 profiles, then you're forced to interact with the notification 3 times if you want to remove the visual distraction from all profiles.

When it comes to the unrelated issue of notification permission prompt spam, requiring explicit user interaction makes sense to me and I appreciate that change in 72.

But requiring 3 explicit user interactions, to remove 3 What's New toolbar notifications from 3 profiles, for each release, arguably decreases the usability of multi-profile support because you effectively get What's New spam proportional to the number of profiles.

Comment 10

[Stephan Sokolow]

(In reply to David Smith from comment #9)

My bias against mandatory notification is that if you have 3 profiles, then you're forced to interact with the notification 3 times if you want to remove the visual distraction from all profiles.

When it comes to the unrelated issue of notification permission prompt spam, requiring explicit user interaction makes sense to me and I appreciate that change in 72.

But requiring 3 explicit user interactions, to remove 3 What's New toolbar notifications from 3 profiles, for each release, arguably decreases the usability of multi-profile support because you effectively get What's New spam proportional to the number of profiles.

Agreed. I also run three profiles (normal, reduced privacy/agency to un-break PayPal's popup checkout flow, nightly testing) and, if forcing browser.messaging-system.whatsNewPanel.enabled in user.js doesn't work out, I plan to open up the XUL inspector and whip up another display: none !important; for my userChrome.css to join the ones for things like #confirmation-hint, #appMenu-fxa-status, and #editBookmarkPanelImage.)

Comment 12

[Andrei Oprea [:andreio]]

The purpose of these prefs is to make sure we have an off switch if something doesn't work correctly, not to offer customization for users. That's why flipping them doesn't always produce the expected result.

The name browser.messaging-system.whatsNewPanel.enabled implies it targets the related panel with a master switch for simple enabling/disabling.

Some context: This pref controls the entry in the applications menu panel. Disabling it will remove that option from the list. However the badging is not related to just the what's new panel (firefox accounts toolbar button can also be badged). Because we know we don't expose an option to turn this off in about:preferences we can always safely signal to Firefox to add the gift icon because we know it will be available.
From our perspective it's working as intended: if we want to turn this feature off we will flip the pref for users and not send the signal to add the gift icon anymore.

Right now this bug is waiting on a new design that will add a user facing option to turn this off. Similar to about:preferences#general -> Browsing

Comment 13

[sworddragon2]

(In reply to Andrei Oprea [:andreio] from comment #12)

(firefox accounts toolbar button can also be badged)

Interestingly I never see this symbol in my current profile. I guess it can be customized out from the symbolbar while the gift icon can't.

But there are some anomalies so I guess I'm just requesting another needinfo:

(In reply to Andrei Oprea [:andreio] from comment #12)

This pref controls the entry in the applications menu panel. Disabling it will remove that option from the list.

I remember on my tests yesterday that even with browser.messaging-system.whatsNewPanel.enabled set to false the entry in the applications menu panel still appeared (but only after the gift icon appeared also in the symbolbar after 300 seconds) so this option seems to not disable it - but unfortunately I can't retest this for safety on a new profile because I do not get the gift icon now at all (I guess because the profile is newer than the last news).

(In reply to Andrei Oprea [:andreio] from comment #12)

From our perspective it's working as intended: if we want to turn this feature off we will flip the pref for users and not send the signal to add the gift icon anymore.

This seems to make no sense: If you can just flip the switch to turn this feature (and gift icon) off if desired but the flip does not intend to turn the gift icon off how does this work together? And why does setting browser.messaging-system.whatsNewPanel.enabled to false disable the gift icon temporary only in the current session?

I guess this leaves a last question: Is there something that speaks against extending browser.messaging-system.whatsNewPanel.enabled to additionaly permanently disable the gift icon in the symbol bar and the entry in the applications menu panel? It should still meet the expected results from the developer side to disable this feature if needed and it would give users a better expectation of this preference. It could also speed up this ticket as an UI-solution (outside of about:config) can still be integrated later (if actually desired).

Comment 15

[Colin Templeman]

(In reply to Andrei Oprea [:andreio] from comment #12)

The purpose of these prefs is to make sure we have an off switch if something doesn't work correctly, not to offer customization for users.

With due respect, customization is precisely why I tweak prefs in user.js and is in fact a major reason why I continue to use Firefox as my preferred browser. Any bloat, feature creep or option choices that I deem insecure or unwanted that are included by default in releases I can ameliorate in this fashion.

The "What's New" toolbar icon and menu entry introduced in FF70 I consider unnecessary and annoying but I could mitigate this with "user_pref("browser.messaging-system.whatsNewPanel.enabled", false);" in user.js.

With the introduction of FF72 this option is ignored or over-ruled which is not the expected behaviour of stanzas added to prefs.js via entries in the user config file. Hence I consider this to be a bug that should be fixed or an introduced feature that should be reversed. Choices in user.js should always be respected.

Comment 16

[Andrei Oprea [:andreio]]

(In reply to sworddragon2 from comment #13)

I found a way to update the badge to not show up if the preference is turned off from about:config. We'll make sure to keep this configuration for future releases as well. Thanks.

Comment 17

[Ron Manning]

Attachment: Preliminary UX design

Comment 18

[Ron Manning]

Comment on attachment 9140538 [details]
Preliminary UX design

Link to preliminary UX design.

https://mozilla.invisionapp.com/share/AVWLN8PEG83#/screens/411069588_Opt_Out_Preference

Comment 19

[Laurence "GreenReaper" Parry]

Looks good to me. The interface is right there and easy enough to understand without being intrusive.

I probably would've jammed it on one side of the header with just the text "Notify" to save adding a new row - but that's why I'm a developer, not a UX designer... and I can understand wanting to leave room for longer translations, as well as getting people to read it at least once. 😼

Comment 20

[Emily McMinn :emcminn]

Attachment: Bug 1599138 - UI update and pref toggle for Whats New Panel

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/aa46487d3145
UI update and pref toggle for Whats New Panel r=andreio,fluent-reviewers,flod

Comment 22

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e6d46fea5cc4
Backed out changeset aa46487d3145 for causing failures in ToolbarPanelHub.jsm

Comment 23

[Alexandru Michis [:malexandru]]

Backed out changeset aa46487d3145 (Bug 1599138) for causing failures in ToolbarPanelHub.jsm

Backout link: https://hg.mozilla.org/integration/autoland/rev/e6d46fea5cc4

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&fromchange=f74cfdb2275ef2546b35cad4ad716d38093d56d2&searchStr=linux%2C18.04%2Cx64%2Copt%2Cnode%2Ctests%2Csource-test-node-newtab-unit-tests%2Cnode%28newtab%29&tochange=05dd19d0ac177958c450b7e11cf47f49b987cb74&selectedJob=299348369

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=299348369&repo=autoland&lineNumber=99

Comment 24

[Emily McMinn :emcminn]

Test coverage issue has been fixed, but we're going to move this into 78 to leave a little more room for QA and testing.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/726b4e2eee2e
UI update and pref toggle for Whats New Panel r=andreio,fluent-reviewers,flod

Comment 26

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/726b4e2eee2e

Comment 27

[Marius Coman [:mcoman], Ecosystem QA]

This enhancement was tested on the latest Nightly 78.0a1 as part of the work done in PI-567. Considering this I am marking the enhancement as VERIFIED.