Open Bug 1703903 Opened 3 years ago Updated 2 years ago

Feature request: settings key that disables all surveys, chatty informational popups, etc etc


(Firefox :: Messaging System, enhancement, P3)

Firefox 87




(Reporter: adamw, Unassigned)



(1 file)

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

Steps to reproduce:

Launched Firefox.

Actual results:

After a while, a "More secure, encrypted DNS lookups" popup appeared and messed up the automated test I was running.

Expected results:

I maintain Fedora's deployment of the openQA automated test system and we use Firefox to test several web browser operations. When we run Firefox in this environment we want it to just open up and show us a web page in the same way, every time. We don't want survey popups, or new feature popups, or any other kind of deviation from the 'normal' process of a browser launch.

Every so often one of these things comes along, and sometimes there's a property you can set in site policy that disables it and sometimes there isn't. But what would be good is a global setting for "never show anything like this ever" that we can just toggle in our "browser setup" phase so we could be confident we just would not have to see one of these break a test run ever again...

The Bugbug bot thinks this bug should belong to the 'Core::Networking: DNS' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Networking: DNS
Product: Firefox → Core

The most appropriate component would I guess be something to do with configuration or policy, but I don't see one.

Component: Networking: DNS → General

Moving to Preferences as a first place to start a discussion here.

Component: General → Preferences
Product: Core → Firefox

Heh, in some coincidental timing, just now one of our automated tests failed on yet another of these things:

our test would like to log in to Cockpit there, not be suddenly bamboozled by a screen about "smarter suggestions" which it has never previously encountered and would like nothing to do with.

Ever confirmed: true

Oh hey, look what broke our tests this time:

can you please stop this, folks? When our automated test system runs Firefox it needs to open Firefox. Not show a survey. Not show a popup about some shiny new feature. Just show the freaking browser, please.

Just to put some concrete data to this: I have now had to spend half an hour searching through the Mozilla code to (I think) find the preference to disable this thing. Every time you add another thing like this, I have to do that (and probably so do a dozen other people with similar cases). It's a big waste of time.

Also, FWIW, the preferences situation here looks sort of...odd? In my own Firefox prefs I seem to have both browser.urlbar.quicksuggest.shouldShowOnboardingDialog and quickSuggestShouldShowOnboardingDialog , which looks like a pretty non-standard name for a Firefox pref. The code looks almost like it's looking for something in the middle of the two, because it does UrlbarPrefs.get("quickSuggestShouldShowOnboardingDialog") - - which sort of looks like it should mean browser.urlbar.quickSuggestShouldShowOnboardingDialog . So I don't actually know which of those two (if either?) works. I guess I'll have to try setting both, and maybe the third one too just to be safe.

Hum, that seems to be the same as the last one, but for some reason it got shown even though our test tries very hard to disable the setting to show it.

sorry for getting overheated, but this is just very annoying, as you can imagine :/

Component: Preferences → Messaging System

To be specific about what would be best for my usage here: if my test just launches Firefox with no arguments, I'm expecting it to launch to a state where the "refresh" and "menu" buttons are visible and normally-colored (not greyed out, dimmed, anything like that), and where the test can click the "new tab" button or send "ctrl-t" and a new tab will open and the test can enter a URL in it. Any kind of pop-up or ad or survey or whatever that makes that not true, breaks the tests.

If my test launches Firefox with a specific URL as an argument, I expect it to launch showing the browser chrome as above, and with that URL loaded in the currently-active tab, and with nothing interfering with normal interaction with that site.

BTW, if anyone knows how to disable the Automated Cookie Protection thing I would appreciate it. I cannot figure it out from just searching the codebase and poking through apparently-relevant commits, and it's breaking a lot of tests right now.

Specifically for the total cookie protection message, you can set privacy.restrict3rdpartystorage.rollout.enabledByDefault to true or false (as a "user pref" not a "default pref') to disable it.

Thanks a lot, I'll add that to the pile.

Firefox's CI sets a lot of prefs, you can look at (and in particular which is the base set of prefs used by almost all our CI). Also if you're using Firefox via WebDriver and not providing your own profile it should be setting enough prefs to get Firefox into a state that's usable for testing; if that isn't happening then file a bug in Testing :: geckodriver.

Thanks, although there seems to be limited overlap with my requirements there. openQA is quite different from a CI system; it effectively attempts to imitate a human tester, matching (specific areas of) screenshots to 'see' what's on the screen, and sending mouse and keyboard events via VNC to do things. I also want the tests to operate in as similar as possible a configuration as an actual human using Fedora would use; every config tweak in a test has the potential to hide a bug that a human not using that tweak would see. So the tests do have public internet access, and actually test that accessing remote sites and doing things on them works. A lot of that config seems concerned with turning off things that trigger remote network accesses.

However, it would be a lot of work (and involve constant 'oh no, a new dialog appeared and the tests are failing, we need to add new screenshot matches fast!' fire drills) to cope with clicking away every new welcome screen someone upstream dreams up, so in that case the benefit of a universal config setting to get rid of these would outweigh the danger of not catching a bug in one of them, for my case.

If anybody would be so kind, btw, my attempt to disable the TCP and quicksearch dialogs doesn't seem to be fully working. It involves writing a file, /usr/lib64/firefox/browser/defaults/preferences/openqa-overrides.js, with this content:

pref('browser.urlbar.quicksuggest.shouldShowOnboardingDialog', false);
pref('quickSuggestShouldShowOnboardingDialog', false);
pref('browser.urlbar.quickSuggestShouldShowOnboardingDialog', false);
pref('privacy.restrict3rdpartystorage.rollout.enabledByDefault', false);

(as noted above, I could not figure from the code which of those three names is actually needed to turn off the quicksuggest thing, so I just put all three candidates I came up with in there). Going by that user.js file, do those lines need to start with user_pref instead of pref? Anywhere else I might be going wrong?

You can just turn off the welcome screen.

You can use OverrideFirstRunPage policy set to "" or set startup.homepage_welcome_url to "".



to false should help as well.

You shouldn't need to go after the dialogs individually.

That would be great if it works for all of these, and future ones. Thanks.

An earlier case I had with this was , which involved "shield studies" that were implemented as a tab Firefox would suddenly open and switch to, rather than a 'welcome screen' like this...

NI @adw to help answer quick suggest pref ask in #comment 17 Thanks

Component: Messaging System → Address Bar
Flags: needinfo?(adw)

sorry, I'm not sure what you want me to answer?

Hi Adam, Need Info is for Andrew (aka adw) to provide feedback on quick suggest prefs used to turn off quick search dialogs. Thanks

Ah, I see, thanks.

Mike, I tried setting OverrideFirstRunPage and OverridePostUpdatePage both to "" in the policy file our tests write, but I already see a case where we still got the total cookie protection popup after doing that: (test writes the config file) (test then launches Firefox and sees the TCP popup)

Sigh, never mind, I just noticed the missing quote mark. I'll see if fixing that solves it.

Nope, still seems to be happening even with the quote mark. :| Is there an about:something which tells you what policies are in effect? That might help me try and figure out what's going on.

Well, I worked out why my config override attempt wasn't working, anyway. I found this page:

which finally pointed me to , which explains the bizarre things you have to do to make preference overrides actually work. None of my previous DDG searches found it. Wow, that's a trip.

My manual tests show that the policy file is working - about:policies shows all the values set in the file if I write the same file in a local VM that we use in the test system and then run Firefox - so I don't know why the TCP page still seems to be showing up even though OverrideFirstRunPage is set to "". It's late here today so I'll poke that more tomorrow.

Along the way I also found out the real name for the quicksuggest pref is browser.urlbar.quicksuggest.shouldShowOnboardingDialog, which was my first guess...

The pref is browser.urlbar.quicksuggest.shouldShowOnboardingDialog. This isn't an address bar bug, so back to the previous component, Messaging System.

Component: Address Bar → Messaging System
Flags: needinfo?(adw)

The Total Cookie Protection early adopter modal was updated to check the usual experiment/study opt-out pref app.shield.optoutstudies.enabled and is now paused/turned off.

Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.