Closed Bug 1599138 Opened 2 years ago Closed 2 years ago

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

Categories

(Firefox :: Messaging System, enhancement, P1)

enhancement

Tracking

()

VERIFIED FIXED
Firefox 78
Iteration:
77.2 - Apr 20 - May 3
Tracking Status
firefox74 --- wontfix
firefox75 --- wontfix
firefox76 --- wontfix
firefox77 --- wontfix
firefox78 --- verified

People

(Reporter: abenson, Assigned: emcminn, NeedInfo)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

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.

Flags: needinfo?(abenson)
Duplicate of this bug: 1589225

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

(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.

Duplicate of this bug: 1605628
Duplicate of this bug: 1607554
Duplicate of this bug: 1607879

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.

Flags: needinfo?(andrei.br92)

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.".

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.

(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.)

Duplicate of this bug: 1608248

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

Flags: needinfo?(andrei.br92)

(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).

Flags: needinfo?(andrei.br92)
Duplicate of this bug: 1608517

(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.

(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.

Flags: needinfo?(andrei.br92)
Blocks: 1601965
Assignee: nobody → emcminn
Iteration: --- → 74.2 - Jan 20 - Feb 09
Priority: -- → P1
Attached file Preliminary UX design

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. 😼

Iteration: 74.2 - Jan 20 - Feb 09 → 77.1 - Apr 6 - Apr 19
Blocks: 1632889
Blocks: 1632985
Pushed by emcminn@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/aa46487d3145
UI update and pref toggle for Whats New Panel r=andreio,fluent-reviewers,flod
Backout by malexandru@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e6d46fea5cc4
Backed out changeset aa46487d3145 for causing failures in ToolbarPanelHub.jsm
Iteration: 77.1 - Apr 6 - Apr 19 → 77.2 - Apr 20 - May 3
No longer blocks: 1632985
Depends on: 1632985

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.

Flags: needinfo?(emcminn)
Pushed by emcminn@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/726b4e2eee2e
UI update and pref toggle for Whats New Panel r=andreio,fluent-reviewers,flod
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 78

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.

Status: RESOLVED → VERIFIED
Blocks: 1714466
You need to log in before you can comment on or make changes to this bug.