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
SABs become foreground-finalizable so that we can access the runtime
during finalization. Then a simple counter on the runtime will track
live SABs for the runtime, and the predicate on the context can get
its information from the runtime.
Fallout: SABs are now enabled on the globals used for jsapi-tests.
Differential Revision: https://phabricator.services.mozilla.com/D55783
--HG--
extra : moz-landing-system : lando
Prevent the l10n overlays logic from parsing markup in Fluent translations when the element being localized is `<title>`. This fixes a regression from bug 1591328 which migrated the browser window title to Fluent, interpolating the current page's title into a Fluent message which is used to localize the window title. If the web page's title contained markup, l10n overlays would parse it—and then sanitize and strip it, which produced an incomplete result visible in the window's title bar and the task bar of the OS.
Differential Revision: https://phabricator.services.mozilla.com/D55784
--HG--
extra : moz-landing-system : lando
Agi Sferro
Aaron Klotz
Brindusan Cristian
Kris Maglione
Andreas Pehrson
Jonathan Watt
Gabriel Luong
Olli Pettay
Jeff Muizelaar
Mark Striemer
Tarek Ziadé
Eugen Sawin
Sylvestre Ledru
Ricky Stewart
Glenn Watson
Jeff Gilbert
Andy Grover
Lars T Hansen
Staś Małolepszy
Alex Henrie
Kris Taeleman
Steve Fink
Chris Manchester