Changes:
Install `gnome-icon-theme` package in the docker image, so the xpcshell test `test_ext_downloads_misc.js` does not fail looking for something that does not exist.
Differential Revision: https://phabricator.services.mozilla.com/D56091
--HG--
extra : moz-landing-system : lando
This patch implements CRLite lookups for TLS server certificate revocation
information in telemetry-only mode. It adds a new preference
"security.pki.crlite_mode" to control the behavior of this feature. Setting
this preference to 0 disables it completely. Setting it to 1 enables telemetry
collection only (the default). Setting it to 2 enables enforcing revocation
information found via CRLite.
Differential Revision: https://phabricator.services.mozilla.com/D54040
--HG--
rename : third_party/rust/bit_reverse/LICENSE-APACHE => third_party/rust/rental/LICENSE-APACHE
rename : third_party/rust/bit-vec/LICENSE-MIT => third_party/rust/rental/LICENSE-MIT
extra : moz-landing-system : lando
Non-AddonManager extensions are invisible to GeckoView, so when a message like
"open a new tab" comes to GeckoView we will ignore them unless the extension is
properly registered.
Because of this, we need to register them in tests too.
Differential Revision: https://phabricator.services.mozilla.com/D56035
--HG--
extra : moz-landing-system : lando
This is a pre-requisite for making extensions persistent, as sometimes we have
to fetch state from Gecko, so getting the extension needs to be async.
Differential Revision: https://phabricator.services.mozilla.com/D55579
--HG--
extra : moz-landing-system : lando
GeckoView will install extensions from the native UI so it doesn't have a
browser object to pass into this method.
Differential Revision: https://phabricator.services.mozilla.com/D55726
--HG--
extra : moz-landing-system : lando
The current shutdown phase is too early and thus may crash when called
by `UntrustedModulesProcessor`. We move it to a later phase such that the
processor has already shut down.
Differential Revision: https://phabricator.services.mozilla.com/D53683
--HG--
extra : moz-landing-system : lando
* The parent process needs to be able to request the child process to provide
its untrusted modules telemetry. This is done via `GetUntrustedModulesData`.
* The child process needs to be able to determine which of its module loads are
trusted, and which are not. Since the child process is sandboxed, it must
delegate that work to the parent process. This is done via `GetModulesTrust`.
* The handlers for these functions just pass the requests on to DLL Services
to do the actual processing.
Differential Revision: https://phabricator.services.mozilla.com/D53682
--HG--
extra : moz-landing-system : lando
* The parent needs to be able to request the child to provide its untrusted
modules telemetry. This is done via `GetUntrustedModulesData`.
* The child needs to be able to determine which of its module loads are trusted,
and which are not. Since the child is sandboxed, it must delegate that work
to the parent process. This is done via `GetModulesTrust`.
Differential Revision: https://phabricator.services.mozilla.com/D53681
--HG--
extra : moz-landing-system : lando
This patch contains the core changes to make this all work across e10s:
* We clarify the naming of path variables to be more specific as to whether they are NT paths or DOS paths;
* We add IPC `ParamTraits` that are necessary for `UntrustedModulesData` types;
* We implement `ProcessModuleLoadQueue` for child processes. Because of sandboxing, we need to split this sequence into multiple async operations:
** Initial queue processing;
** Sending the list of modules to the parent process to determine trustworthiness (via `GetModulesTrust`);
** Receiving the results from the parent process and producing a final result (via `CompleteProcessing`).
* We implement the `GetModulesTrust` function for the parent process, which evaluates the trust of child process modules;
* We change all hash tables to be keyed using NT paths. Because resolving DOS paths may not be permitted in sandboxed processes,
we need to standardize on NT paths as the "universal path" across processes.
* We add `WinDllServices::StartUntrustedModulesProcessor` to separate untrusted modules startup from `WinDllServices` construction:
** While we now start `WinDllServices` across all child process types, only specific process types will support untrusted modules.
** Furthermore, untrusted modules must be started at a very specific point that is dependent on the type of child process.
** We add those calls to `StartUntrustedModulesProcessor` in subsequent patches.
Differential Revision: https://phabricator.services.mozilla.com/D53680
--HG--
extra : moz-landing-system : lando
When launching a sandboxed child process that uses `firefox.exe`, we now
perform early initialization of the DLL blocklist.
Differential Revision: https://phabricator.services.mozilla.com/D53679
--HG--
extra : moz-landing-system : lando
We need a way for the sandbox broker to be able to initialize the launcher
DLL blocklist when starting a new content process.
This patch adds the ability to resolve the initialization function through
DLL services.
Differential Revision: https://phabricator.services.mozilla.com/D53678
--HG--
extra : moz-landing-system : lando
`LauncherResult` only includes file and line info when built into the launcher
process. Now that there will be `xul.dll`-based code calling into launcher
process startup, this would create an ABI mismatch.
This patch creates a new type, `LauncherResultWithLineInfo`, that
unconditionally includes the file and line so that APIs called by both `xul`
and non-`xul` code can have the same ABI for both.
Differential Revision: https://phabricator.services.mozilla.com/D53677
--HG--
extra : moz-landing-system : lando
Now that the launcher blocklist will support child processes, we need to add
them to the launcher blocklist. The revised criteria the `Launcher` blocklist
matches the criteria already in use by the `Legacy` blocklist.
Differential Revision: https://phabricator.services.mozilla.com/D53675
--HG--
extra : moz-landing-system : lando
* We change `InitializeDllBlocklistOOP` to be able to set the correct flags
when initializing a sandbox child process.
* We change the freestanding DLL blocklist code to be sensitive to the
`CHILD_PROCESSES_ONLY` flag;
* We move the declaration of `gBlocklistInitFlags` to `WindowsDllBlocklist.h`
so that it is visible to more code.
Differential Revision: https://phabricator.services.mozilla.com/D53674
--HG--
extra : moz-landing-system : lando
When we initialize the legacy blocklisting code, we should carry forward any
flags that were set by the launcher process and/or sandbox launcher.
Differential Revision: https://phabricator.services.mozilla.com/D53672
--HG--
extra : moz-landing-system : lando
It only works in the parent process, and if we wind up falling back to it in a
content process, it can only cause trouble.
Differential Revision: https://phabricator.services.mozilla.com/D56059
--HG--
extra : moz-landing-system : lando
There is no need for this code to set the kEnableSelectionRB bit. nsPrintJob
already sets it before it calls nsIPrintingPromptService::ShowPrintDialog.
Differential Revision: https://phabricator.services.mozilla.com/D55992
--HG--
extra : moz-landing-system : lando
It looks like there is going to be a period of LSNG being disabled on some channels for a while.
Making the test conditional on the pref will make it pass in all situations and would allow us to keep the test enabled.
It doesn't help with the fact, that on some version we're clearing storage despite the flag not being set, but since it's clearing more, rather than less, it's at least not as critical in terms of privacy.
Differential Revision: https://phabricator.services.mozilla.com/D55526
--HG--
extra : moz-landing-system : lando
With the native compositor enabled, try runs were occasionally
hitting an assertion failure where a compositor surface was
being drawn, but hadn't been created (so the id was unknown).
This was occurring when the MemoryPressure event occurs in some
situations during shutdown. When this occurs, the active_documents
list is cleared. This could result in the native surface updates
list (which was stored in the Frame of a Document) not being
applied, meaning the new surface was not created. If a subsequent
frame then tried to composite that surface, this assert would
occur.
This is fixed by moving compositor surface management to be handled
via the resource cache, in the same way as texture cache updates.
This ensures that even in the presence of a memory pressure event,
any pending native surface updates are applied to the renderer.
Differential Revision: https://phabricator.services.mozilla.com/D55910
--HG--
extra : moz-landing-system : lando
