1624133 - Do not show me Pocket when I have Pocket disabled

Status: UNCONFIRMED

(Firefox :: New Tab Page, defect, P3)

Description

[Cole Mickens]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

1. Use about:config to disable pocket (extensions.pocket.api=gibberish, extensions.pocket.enabled=false, extensions.pocket.site=gibberish, browser.newtabpage.activity-stream.section.highlights.includePocket=false)

2. Upgrade Nightly.

3. Check about:config, all Pocket-related options are still off/hampered.

Actual results:

I observe Pocket on my Firefox Home screen. This has happened maybe a half a dozen times or more in the last month of being on Nightly.

Expected results:

I should not see Pocket, ever. Not as a mozilla.org new install/upgrade feature upsell. Not as a Firefox Homescreen ad. Not as a re-occurring feature that seem to ignore it's own feature disable-flag.

Pocket seems to be a recurring issue. Would Mozllla support a flag that would finally fully and permanently disable Pocket in Firefox?

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Scott [:thecount] Downe]

There are two areas with pocket usage, and two official ways to disable them. If either of these do not stick after an update, that's most definitely a bug and not a feature. We've had reports of this from other users, but I've never been able to reproduce this issue and I don't know what's causing it.

The two places where we have pocket, and how to disable them.

1. In the address bar, right click the pocket icon, and click "Remove from Address Bar"
2. Go to about:preferences#home and click the checkbox for "Recommended by Pocket"

This should disable it, and it should keep it that way.

You've likely tried both of these already, which strongly suggests this is a bug.

Any info you can give me that can help me reproduce this issue, using the two methods above, would help me a lot.

One question that comes to mind that might help me debug: Are you using Firefox sync at all? Either way, try setting this pref to false: services.sync.prefs.sync.browser.newtabpage.activity-stream.feeds.section.topstories and then turn off browser.newtabpage.activity-stream.feeds.section.topstories too and see if the issue happens again next nightly update.

Comment 3

[Cole Mickens]

Hi Scott! Thank you for the summary, you would be right that I've taken those steps. Unfortunately I don't have any other data or even guesses at repro steps.

Just to capture this while it's fresh - when I filed this bug I was not using Firefox Sync. I have since started using it, but will likely abandon it again since it still requires MAC for container sync. I have not had this issue reoccur since then. I will pay close attention to the firefox account status if it repros again.

For my understanding, it would help me to understand something sort of basic, I guess -- for every setting in Firefox Settings/Preferences, is there expected to be something in about:config that I can see toggle? Do the two things you listed correspond to certain about:config keys?

Just re-iterate/clarify, when I setup a new Firefox profile, the first thing I do is pop open about:config and change the Pocket options mentioned in the first post, as well as some other options related to firefox accounts/mostrecently-tab switching/auto-hide fullscreen. So my expectation is that when I disable pocket and cripple the api endpoints... that even if Pocket somehow appears, when it reaches to the API, it should just fail. Or are those keys not honored, or are they misleading in name?

Comment 4

[Scott [:thecount] Downe]

Not every config setting or state change in firefox is stored in a pref, and not every pref is a config setting. It's just a relatively easy way to store and change some sort of state or config.

I imagine most settings in about:preferences are n fact in a pref, but it's not a rule. It's more likely the place to store it that makes sense to the team implementing the feature, and the needs of the feature, determine where we would store the state.

In the specific case of everything under "Firefox Home Content" in about:preferences#home, they do happen to all have corresponding prefs. Again, that's not a rule, that's just where it made sense to store each of those. (I could list all the prefs for those configs if you're curious :D)

The values in about:config are generally for developer usage. You're free to change them, and if you disable some of these endpoints at their source, it may be very effective in what you're trying to achieve, but the downsides to this is the developers might remove, rename, or change them without warning. It also means the name of the values in there might not be super obvious to their purpose.

In the case of the prefs you listed in the initial comment, I think most are related to the save to pocket button in the address bar, and may work as expected. This one though "includePocket" is used to decide if we want to include pocket stories in highlights that are already being displayed, so likely not what you want. browser.newtabpage.activity-stream.feeds.section.topstories is the most direct. You can also set browser.newtabpage.activity-stream.discoverystream.endpoints to gibberish, but it's not obvious to me how long it would take for cache to expire and the stories to be removed.

Comment 5

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)