This could be a bit risky to enable in any widespread fashion, but the
goal here is just to land it behind an undocumented command line flag
so that we can do a bit of experimentation and dogfooding. The API
seems to work exactly as desired: firefox opens in the background
without a window or dock icon. Upon trying to launch firefox again, we
simply send a remote command to the existing instance to open a window,
and it does so and gets a dock icon.
Differential Revision: https://phabricator.services.mozilla.com/D126054
* Add a new browser.startup.couldRestoreSession.count which counts up (max 2) each time we *could* restore a session
* Show the new infobar notification when that count reaches 1 (i.e. skip it on the first startup after update)
* New strings for the notification - including an inline icon image for the ☰
* The notification's button opens the app menu.
* Allow Opt-out with a pref value of -1, and opt-out the testing user by default so our perf tests don't trip on it.
Differential Revision: https://phabricator.services.mozilla.com/D125904
* Add a new browser.startup.couldRestoreSession.count which counts up (max 2) each time we *could* restore a session
* Show the new infobar notification when that count reaches 1 (i.e. skip it on the first startup after update)
* New strings for the notification - including an inline icon image for the ☰
* The notification's button opens the app menu.
Differential Revision: https://phabricator.services.mozilla.com/D125904
This patch introduces a new pref, devtools.every-frame-target.enabled,
that when set to true will cause target actors to be created on every
iframe, no matter if they are remote or not, no matter if Fission is
enabled or not.
This adds a ignoreSubFrames property on the BrowsingContextActor so
it can focus solely on the docShell it was passed.
Differential Revision: https://phabricator.services.mozilla.com/D125517
This will allow starting Firefox in the background, and on Windows will allow
closing the last browser window without killing the main process. There is no
plan for actually using this by default in Firefox proper, but it's needed for
some explorations.
There's more to this work that we'll need - this is just the first step. For
instance, we'll need a real way to actually kill firefox on Windows other than
through the task manager (we'll be putting something in the system tray to
allow this.)
The patch wasn't particularly large, so I didn't split out the rename of
MOZ_APP_SILENT_START to MOZ_APP_SILENT_RESTART - let me know if you'd like me
to do that though and I can.
Differential Revision: https://phabricator.services.mozilla.com/D124249
This adds a `quickSuggestScenario` Nimbus variable.
We could use the `quickSuggestShouldShowOnboardingDialog` variable to
distinguish between offline and online on the client, since offline won't get
the onboarding but online will. However, using a separate variable would be
clearer and possibly less confusing for stakeholders, and it would also allow us
to have finer control over the onboarding prompt if we need it.
We'll need to distinguish between the two scenarios on the client for telemetry
pings, tweaks to the preferences UI, and possibly other things.
Differential Revision: https://phabricator.services.mozilla.com/D124844
The Jira ticket (link in the bug) calls for two separate checkboxes for Firefox
Suggest results: a main checkbox plus a sponsored-suggestions checkbox. The
sponsored-suggestions checkbox is subordinate to the main checkbox, i.e., the
main checkbox has to be checked to turn on sponsored suggestions. This will
allow users to toggle sponsored suggestions separately from non-sponsored
suggestions. It's a change from the current situation where we have only one
pref and checkbox that control both sponsored and non-sponsored suggestions.
So part 1 of fixing this bug is to add a new pref for sponsored suggestions.
This revision keeps the current `suggest.quicksuggest` pref as the main pref and
adds a new `suggest.quicksuggest.sponsored` pref. I confirmed with Natalie that
we want to enable both prefs when the user opts in through the onboarding
dialog.
We currently record a telemetry event when `suggest.quicksuggest` is toggled. We
also want a similar event for the new pref, so this adds one.
The pref situation for Firefox Suggest is confusing but in summary:
* `browser.urlbar.quicksuggest.enabled`: The global toggle for the entire
Firefox Suggest rollout involving sponsored and non-sponsored suggestions, the
related telemetry and preferences UI, etc. This pref can be overridden by the
`quickSuggestEnabled` Nimbus variable. If false, neither sponsored nor
non-sponsored suggestions will be shown. If true, then we look at the
individual `suggest.quicksuggest` and `suggest.quicksuggest.sponsored` prefs.
* `browser.urlbar.suggest.quicksuggest`: Whether any Firefox Suggest results are
shown. This must be true to show both non-sponsored and sponsored results.
* `browser.urlbar.suggest.quicksuggest.sponsored`: Whether sponsored Firefox
Suggest results are shown. Both this pref and `suggest.quicksuggest` must be
true to show sponsored results.
Differential Revision: https://phabricator.services.mozilla.com/D124300
This patch adds a new flag to the ContentBlockingCategoriesPrefs and
enable the feature in strict mode and PBM. Also, this patch set the pref
to true in the ETP custom mode.
Differential Revision: https://phabricator.services.mozilla.com/D123769
This integrates a fetch to Merino in UrlbarProviderQuickSuggest. We continue to
do the remote settings fetch too. Per the Jira ticket, we should prefer the
Merino suggestion when both sources return one.
Each fetch is controlled by a new pref and Nimbus variable, so we can enable
them independently.
At first I started making a UrlbarProviderMerino class, but it's better to
modify UrlbarProviderQuickSuggest because everything besides the fetch source is
the same: We want to collect the same telemetry, have the same results and
payloads, etc.
Depends on D123852
Differential Revision: https://phabricator.services.mozilla.com/D123707
Automatically generated path that adds flag `REQUIRES_UNIFIED_BUILD = True` to `moz.build`
when the module governed by the build config file is not buildable outside on the unified environment.
This needs to be done in order to have a hybrid build system that adds the possibility of combing
unified build components with ones that are built outside of the unified eco system.
Differential Revision: https://phabricator.services.mozilla.com/D122345
This patch removes the `extensions.webextPermissionPrompts` pref as well as
`permissionPromptsEnabled` prop on `mozAddonManager`.
While working on this patch, we noticed that some of the `browser_webapi.js`
weren't testing anything for a while now. That has been fixed. In addition,
the `test_blocklistchange.js` file has been updated to handle the permissions
prompt.
Differential Revision: https://phabricator.services.mozilla.com/D121114
This patch doesn't cover turning the launcher process back on, because that already happens automatically during the PostUpdate process.
Differential Revision: https://phabricator.services.mozilla.com/D120507
Haik Aftandilian
Doug Thayer
Andrei Oprea
Michael Kohler
Csoregi Natalia
Scott
Sam Foster
Sandor Molnar
Nicolas Chevobbe
Neil Deakin
Bob Owen
Dan Mosedale
Punam Dahiya
Tim Huang
Marian-Vasile Laza
Harry Twyford
Drew Willcoxon
Kirk Steuber
Dão Gottwald
Andi-Bogdan Postelnicu
Toshihito Kikuchi
Gavin Lazar Suntop
William Durand
Julian Descottes