This isn't strictly necessary, but 'App' is what most Apps seem to use, so we may as well too.
Also ensures 'en-US' is the first listed language, to make it the default.
Differential Revision: https://phabricator.services.mozilla.com/D132194
We take this opportunity to merge the browser toolbox and content toolbox preferences
into a single one.
Depends on D131600
Differential Revision: https://phabricator.services.mozilla.com/D131770
We take this opportunity to merge the browser toolbox and content toolbox preferences
into a single one.
Depends on D131600
Differential Revision: https://phabricator.services.mozilla.com/D131770
When the launcher process is enabled, Puppeteer, or any other automation tools, cannot
have control of the lifetime of the browser process even though the `--wait-for-browser`
option is used.
This patch is to include the launcher process and the browser process to a job to enable
a launcher of the launcher process like Puppeteer to terminate the application by terminating
the launcher process if `--wait-for-browser` is set.
Differential Revision: https://phabricator.services.mozilla.com/D131170
When the launcher process is enabled, Puppeteer, or any other automation tools, cannot
have control of the lifetime of the browser process even though the `--wait-for-browser`
option is used.
This patch is to include the launcher process and the browser process to a job to enable
a launcher of the launcher process like Puppeteer to terminate the application by terminating
the launcher process if `--wait-for-browser` is set.
Differential Revision: https://phabricator.services.mozilla.com/D131170
Turn off by default as "Mikal won't want to see us ship another experience devoid of the pin and set to default prompts."
Differential Revision: https://phabricator.services.mozilla.com/D131023
Bug 1420363 changed the type of `WriterFn`'s parameter from `HANDLE` to
`AnnotationWriter&` and rewrote `InternalWriteNotes` in mozglue.dll, but
it didn't update `NativeNtBlockSet_Write` in firefox.exe, which is used
when the launcher process is enabled.
This patch applies a part of D46848 to `NativeNtBlockSet_Write`.
Differential Revision: https://phabricator.services.mozilla.com/D130921
Now that we're likely not targeting a 94 dot release anymore, I'd like to go
ahead and rename the `suggest.quicksuggest` pref to
`suggest.quicksuggest.nonsponsored` as we considered doing before. There won't
be a better time to do it.
Depends on D128665
Differential Revision: https://phabricator.services.mozilla.com/D130565
This is a big revision that makes a lot of changes. The core change is adding a
new pref to control data collection for Firefox Suggest and making the existing
non-sponsored and sponsored prefs independent of each other. The data-collection
pref defaults to false in every scenario; in online, the user is opted in to it
when they opt in to the modal, and in both online and offline the user will be
able to enable it in the preferences UI (part 2 of this bug, see below).
A new requirement for this bug that came up after I wrote my original patch in
D128579 is that we want the ability to enable Merino via an experiment, which
requires the data-collection pref to be true. That's tricky because data
collection will be exposed in the preferences UI. If the user disables it, we
don't want to override that. There's a distinction to draw between its being
disabled/enabled by default and its being disabled/enabled by the user. It's OK
to override the default but not the user's choice, and that's true not only for
this new data-collection pref but for all prefs exposed in the UI.
We can handle that by taking care to set prefs on the default and user branches
as appropriate. If a pref exposed in the UI has a value on the user branch, then
we can assume the user modified it, and ideally that value should stick around
indefinitely. On the other hand we can set default values as configured by
Nimbus on the default branch. If the user modified a pref, then it'll take
precedence since it's on the user branch.
To make user-modified preferences stick around indefinitely, I made them sticky
in firefox.js. That way even when user values are the same as default values,
the user-branch values will be preserved, which is not true of non-sticky prefs.
I added a new Nimbus variable for data collection, so we can use that to enable
it by default. It was trivial to add similar variables for the other UI-exposed
prefs, the two suggestions types, so I did that too.
This is all tested pretty thoroughly in browser_quicksuggest_configuration.js.
This is only part 1 of 4. Part 2 updates the prefs UI, part 3 adds telemetry for
the new data-collection pref (event telemetry when it's toggled, similar to the
existing prefs, and telemetry environment), and part 4 changes the name of
`browser.urlbar.suggest.quicksuggest` to
`browser.urlbar.suggest.quicksuggest.nonsponsored`.
For review, I'd suggest looking at parts in the following order:
1. UrlbarPrefs.jsm, browser_quicksuggest_configuration.js, and
test_quicksuggest_migrate.js.
The core changes are in UrlbarPrefs.jsm. The two test files document the
expected behavior of different scenarios/enrollments and prefs migrations.
browser_quicksuggest_configuration.js tests different enrollments and the
prefs stuff I mentioned above.
test_quicksuggest_migrate.js tests prefs migrations. I added a migration step
that's run on startup when the scenario is updated. There are two things we
need to do: decouple the existing `suggest.quicksuggest` prefs and initialize
the new data-collection pref. (For brevity I'll omit the `browser.urlbar`
prefix to all these pref names in this commit message.)
The `suggest.quicksuggest` pref now controls non-sponsored suggestions, and
the `suggest.quicksuggest.sponsored` now controls sponsored suggestions
independent of the other pref. The new data pref is
`quicksuggest.dataCollection.enabled`.
For the current online rollout on 92.0.1, we don't record the user's choice
to the opt-in modal, so the initial value of the data pref for existing users
is debatable. I Slacked with Natalie about it, and we think it's OK to
initialize it to allow data collection as long as the main
`suggest.quicksuggest` pref is true. The user may not have opted in to the
modal in that case, but if not, they enabled suggestions in
about:preferences, where we show a description under the main Firefox Suggest
checkbox about data sharing.
For new profiles (i.e., profiles that are created in versions of Firefox
where this revision has landed), the migration step runs but is effectively a
no-op.
2. UrlbarProviderQuickSuggest.jsm and UrlbarProviderQuickSuggest.jsm. The
changes here are again related to decoupling the `suggest.quicksuggest` prefs
and checking the data pref before recording data in telemetry and fetching
from Merino.
3. All the other tests. I ended up adding some checks to a lot of them and
simplifying some, especially browser_urlbar_telemetry_quicksuggest.js.
Depends on D130531
Differential Revision: https://phabricator.services.mozilla.com/D129224
This adds a 200ms timeout using `setTimeout` and the current `AbortController`.
The timeout value can be set in prefs and Nimbus.
It also modifies SkippableTimer in UrlbarUtils.jsm so canceling and firing are
idempotent.
Depends on D130429
Differential Revision: https://phabricator.services.mozilla.com/D129772
Firefox.exe has its own function table of Kernel32's functions so that we can
use them before the executable's import table is resolved. The table is in
the shared secion, where the launcher process puts the offsets of the functions
and the browser process resolves them to the function addresses.
The problem is when the browser process calls `GetDependentModulePaths` to get
the list of dependent modules that is also in the shared section, it remapped
the write-copy view to get the list visible in the mapped view. As a side-effect
of this remapping, the function addresses are gone and the browser process cannot
use the `RedirectToNoOpEntryPoint` blocking technique. This is not a problem in
the production environment, but it caused GTest failures.
After I examined the events carefully as below, it turns out that this remapping
is not really needed because `GetDependentModulePaths` is used when we launch
a child process with pre-spawn CIG, which is long after all the dependent modules
are loaded.
1. Browser process gets a writeble handle via the shared section
2. Add dependent modules to the writable view (before the process's entrypoint)
3. `firefox!wmain` calls `ConvertToReadOnly()` to convert the writable handle to
a readonly handle
4. The first module loading maps a write-copy view, which contains a complete
list of the dependent modules
5. Or, the first call to `GetDependentModulePaths()` maps a write-copy view
(No need to remap the view here)
When the browser process calls `GetDependentModulePaths`, the list of the dependent
modules are complete and there is no needed to remap it.
The proposed fix is to remove the line remapping the section.
Differential Revision: https://phabricator.services.mozilla.com/D130433
This adds a new cross call using the chromium shared memory IPC to proxy use of
the Uniscribe line breaker, because it cannot be used in the content process
with win32k lockdown enabled.
If the text being processed is too long to fit into the IPC params then it is
processed in chunks.
This change implements an INPTR_TYPE in the sandbox, which appears to have
been removed at some point.
It also fixes a bug in OpcodeFactory::MakeOpAction, so that a null param is
passed and we can use an empty parameter set.
New files are in chromium-shim as these are most likely to require changes and
this means we will not have to update the main chromium patch.
Depends on D129125
Differential Revision: https://phabricator.services.mozilla.com/D126809
To more properly support Linux having a different default at runtime.
Expose the resolved value in appinfo for convenience, and use it in the
front-end as needed.
Differential Revision: https://phabricator.services.mozilla.com/D129004
Enable tab unloading on macOS when the OS memory pressure level reaches "critical".
Add a gtest that exercises the memory pressure response by testing that a tab unload attempt occurs and the internal memory-pressure notification is sent. Test does not cause a real OS memory pressure event.
Use the memory_pressure(1) macOS command to generate artificial memory pressure events to test the browser response. For example, the following artificially puts the OS in the "critical" memory pressure level for 60 seconds.
`$ sudo memory_pressure -S -l critical -s 60`
Differential Revision: https://phabricator.services.mozilla.com/D126560
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