PrefetchRegistryInfo is intended to be a temporary file in order to conduct
this experiment on startup times vs. retention.
Most of the implementation is similar to LauncherRegistryInfo.
If we startup and the registry is different than the preference,
we will want to use the preference for the purpose of this experiment.
Differential Revision: https://phabricator.services.mozilla.com/D76993
MOZ_PROFILE_GENERATE is already defined in mozilla-config.h and doesn't
need to be re-defined by the moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D65210
--HG--
extra : moz-landing-system : lando
A fix for Bug 1588975 replaced the call to `LaunchWithIProcess` in
`nsMIMEInfoWin::LaunchWithFile` with the call to `ShellExecuteWithIFile` to use
`mozilla::ShellExecuteByExplorer`. This caused a regression that if a filepath
contains whitespaces, we pass it to a target application without quoting it
while the old codepath `ShellExecuteWithIFile` quoted a path accordingly in
`assembleCmdLine`.
A proposed fix is to quote a path in the same way as `assembleCmdLine` does.
This patch also moves `assembleCmdLine` to an exported header so that we can add
a unittest to cover both of `assembleCmdLine` and a new function
`assembleSingleArgument. It would be better to refactor these functions in the
future because many lines are duplicated.
Differential Revision: https://phabricator.services.mozilla.com/D56646
--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
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
* Significant cleanup to `ModuleEvaluator`
* `UntrustedModuleData` holds all of the accumulated untrusted module info for
a single process.
* `ProcessedModuleLoadEvent` holds information about an individual untrusted
module load in a Gecko-friendly, sanitized, format.
* Since multiple `ProcessModuleLoadEvent` objects may reference the same
module, we store module metadata in a shared `ModuleInfo` structure.
* The `UntrustedModulesProcessor` receives the events from `mozglue` and
processes them on a background thread:
** It does not start background processing until the main thread has gone idle.
The idea here is that we do not want to add any more background work until
we are reasonably confident that Gecko is no longer starting up or doing
other intense activity.
** Background processing runs at a background priority level, *except* when
results are requested by telemetry itself.
** Telemetry requests the data via `UntrustedModulesProcessor::GetProcessedData`
which runs at normal priority and returns a promise to the caller.
Depends on D43159
Differential Revision: https://phabricator.services.mozilla.com/D43160
--HG--
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.cpp
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.h
rename : toolkit/xre/ModuleVersionInfo_windows.cpp => toolkit/xre/ModuleVersionInfo.cpp
rename : toolkit/xre/ModuleVersionInfo_windows.h => toolkit/xre/ModuleVersionInfo.h
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesData.cpp
rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesData.h
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesProcessor.cpp
rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesProcessor.h
extra : moz-landing-system : lando
* Significant cleanup to `ModuleEvaluator`
* `UntrustedModuleData` holds all of the accumulated untrusted module info for
a single process.
* `ProcessedModuleLoadEvent` holds information about an individual untrusted
module load in a Gecko-friendly, sanitized, format.
* Since multiple `ProcessModuleLoadEvent` objects may reference the same
module, we store module metadata in a shared `ModuleInfo` structure.
* The `UntrustedModulesProcessor` receives the events from `mozglue` and
processes them on a background thread:
** It does not start background processing until the main thread has gone idle.
The idea here is that we do not want to add any more background work until
we are reasonably confident that Gecko is no longer starting up or doing
other intense activity.
** Background processing runs at a background priority level, *except* when
results are requested by telemetry itself.
** Telemetry requests the data via `UntrustedModulesProcessor::GetProcessedData`
which runs at normal priority and returns a promise to the caller.
Differential Revision: https://phabricator.services.mozilla.com/D43160
--HG--
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.cpp
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.h
rename : toolkit/xre/ModuleVersionInfo_windows.cpp => toolkit/xre/ModuleVersionInfo.cpp
rename : toolkit/xre/ModuleVersionInfo_windows.h => toolkit/xre/ModuleVersionInfo.h
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesData.cpp
rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesData.h
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesProcessor.cpp
rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesProcessor.h
extra : moz-landing-system : lando
* Significant cleanup to `ModuleEvaluator`
* `UntrustedModuleData` holds all of the accumulated untrusted module info for
a single process.
* `ProcessedModuleLoadEvent` holds information about an individual untrusted
module load in a Gecko-friendly, sanitized, format.
* Since multiple `ProcessModuleLoadEvent` objects may reference the same
module, we store module metadata in a shared `ModuleInfo` structure.
* The `UntrustedModulesProcessor` receives the events from `mozglue` and
processes them on a background thread:
** It does not start background processing until the main thread has gone idle.
The idea here is that we do not want to add any more background work until
we are reasonably confident that Gecko is no longer starting up or doing
other intense activity.
** Background processing runs at a background priority level, *except* when
results are requested by telemetry itself.
** Telemetry requests the data via `UntrustedModulesProcessor::GetProcessedData`
which runs at normal priority and returns a promise to the caller.
Differential Revision: https://phabricator.services.mozilla.com/D43160
--HG--
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.cpp
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.h
rename : toolkit/xre/ModuleVersionInfo_windows.cpp => toolkit/xre/ModuleVersionInfo.cpp
rename : toolkit/xre/ModuleVersionInfo_windows.h => toolkit/xre/ModuleVersionInfo.h
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesData.cpp
rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesData.h
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesProcessor.cpp
rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesProcessor.h
extra : moz-landing-system : lando
* Significant cleanup to `ModuleEvaluator`
* `UntrustedModuleData` holds all of the accumulated untrusted module info for
a single process.
* `ProcessedModuleLoadEvent` holds information about an individual untrusted
module load in a Gecko-friendly, sanitized, format.
* Since multiple `ProcessModuleLoadEvent` objects may reference the same
module, we store module metadata in a shared `ModuleInfo` structure.
* The `UntrustedModulesProcessor` receives the events from `mozglue` and
processes them on a background thread:
** It does not start background processing until the main thread has gone idle.
The idea here is that we do not want to add any more background work until
we are reasonably confident that Gecko is no longer starting up or doing
other intense activity.
** Background processing runs at a background priority level, *except* when
results are requested by telemetry itself.
** Telemetry requests the data via `UntrustedModulesProcessor::GetProcessedData`
which runs at normal priority and returns a promise to the caller.
Differential Revision: https://phabricator.services.mozilla.com/D43160
--HG--
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.cpp
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/ModuleEvaluator.h
rename : toolkit/xre/ModuleVersionInfo_windows.cpp => toolkit/xre/ModuleVersionInfo.cpp
rename : toolkit/xre/ModuleVersionInfo_windows.h => toolkit/xre/ModuleVersionInfo.h
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesData.cpp
rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesData.h
rename : toolkit/xre/ModuleEvaluator_windows.cpp => toolkit/xre/UntrustedModulesProcessor.cpp
rename : toolkit/xre/ModuleEvaluator_windows.h => toolkit/xre/UntrustedModulesProcessor.h
extra : moz-landing-system : lando
`WindowsErrorResult` is a class to hold either a value or a Windows error
code based on the `Result` template. We also have `LauncherResult` for the
same purpose, which was introduced as a part of the launcher process feature
afterward. The difference is `LauncherResult` holds a filename and line
number along with an error code.
This patch integrates LauncherResult.h into WinHeaderOnlyUtils.h so that we
can use `LauncherResult` more broadly.
Differential Revision: https://phabricator.services.mozilla.com/D44512
--HG--
extra : moz-landing-system : lando
This patch adds a new Scalar metric `os.environment.is_admin_without_uac` that
indicates the process is lauched with Admin privileges when UAC is turned off.
Differential Revision: https://phabricator.services.mozilla.com/D42047
--HG--
extra : moz-landing-system : lando
This patch adds a new Scalar metric `os.environment.is_admin_without_uac` that
indicates the process is lauched with Admin privileges when UAC is turned off.
Differential Revision: https://phabricator.services.mozilla.com/D42047
--HG--
extra : moz-landing-system : lando
This patch addresses both Bug 1551913 and Bug 1552206.
This patches the update directory permission-fixing code.
This also fixes a related bug that I discovered while testing this patch: nsAutoSid doesn't actually work because both PSID and HANDLE are both typedef'ed from void*, so the compiler can't actually tell the difference between them and ends up calling CloseHandle instead of FreeSid. To fix this, I removed nsAutoSid and replaced it with UniqueSidPtr, a UniquePtr type that uses a custom deleter class to free the SID properly.
Differential Revision: https://phabricator.services.mozilla.com/D34941
--HG--
rename : toolkit/mozapps/update/common/win_dirent.cpp => toolkit/mozapps/update/common/updateutils_win.cpp
rename : toolkit/mozapps/update/common/win_dirent.h => toolkit/mozapps/update/common/updateutils_win.h
extra : moz-landing-system : lando
We build compatibility versions as `<appversion>_<appbuildid>/<platformbuildid>`.
where the build ID's by default are a numeric representation of the date that
the build happened.
Previously we attempted to mangle this into a valid toolkit version by
converting to `<appversion>.<appbuildid>.<platformbuildid>` if the build IDs
were the expected length. We also split each build ID into two version parts
since the version comparator couldn't handle their full size.
This mangling fails when comparing a major version with a new patch version:
`<majorversion>.<appbuildid>.<platformbuildid>` gets compared to
`<majorversion>.1.<appbuildid>.<platformbuildid>`. Unless that patch version
(1 here) was greater than the build ID (currently in the tens of millions) the
patch release would appear to be older than the previous version.
This changes this so rather than attempting to mangle the entire string into a
single toolkit version we split out the string into their components.
First we compare the app versions using the version comparator which is
definitely the correct thing to do.
For the build IDs we check if they are entirely numeric (which is the case for
the date based default) and if so just compare them numerically.
We assume that if the IDs aren't numeric then they are something defined by a
custom build of Firefox, we can't know what form that takes so I've chosen to
fallback to just using the version comparator since it will handle things such
as `"build1" < "build10"` and it should be straightforward for anything more
complex to choose a form that works.
Differential Revision: https://phabricator.services.mozilla.com/D32552
--HG--
extra : rebase_source : 926d1f9f8cedad099b0d1813acf1342b50ed0217
When Android shuts down the ndk process, it doesn't call the registered
atexit() handlers, which is normally where the profile data gets written
to file. Since the PGO test suite closes the browser when it is
finished, the nativeRun routine can manually call out to
__llvm_profile_dump() before returning.
This method has a downside that only the profile data from the calling
library gets written out, rather than for the whole process. Since we
are most interested in optimizing libxul, a new hook is added in
Bootstrap to make sure we get the profile data for the right library.
Differential Revision: https://phabricator.services.mozilla.com/D22817
--HG--
extra : source : 0615c775a0cf6e8f98e1c051cd574c0d602a738a
When Android shuts down the ndk process, it doesn't call the registered
atexit() handlers, which is normally where the profile data gets written
to file. Since the PGO test suite closes the browser when it is
finished, the nativeRun routine can manually call out to
__llvm_profile_dump() before returning.
This method has a downside that only the profile data from the calling
library gets written out, rather than for the whole process. Since we
are most interested in optimizing libxul, a new hook is added in
Bootstrap to make sure we get the profile data for the right library.
Differential Revision: https://phabricator.services.mozilla.com/D22817
--HG--
extra : moz-landing-system : lando
Adds build config and stubs for a windows implementation of the remote client
and server.
Differential Revision: https://phabricator.services.mozilla.com/D19074
--HG--
extra : source : abd7789e9637c92978efcf745361b98c5abf847a
extra : intermediate-source : 276ca640adc8ff16ff3ff7252e8aa5016205b1e0
This code is only ever used from c++ so does not need to be an XPCOM component.
Broken out a single nsRemoteService that is responsible for choosing the server
implementation to use.
Differential Revision: https://phabricator.services.mozilla.com/D19067
--HG--
rename : toolkit/components/remote/nsDBusRemoteService.cpp => toolkit/components/remote/nsDBusRemoteServer.cpp
rename : toolkit/components/remote/nsDBusRemoteService.h => toolkit/components/remote/nsDBusRemoteServer.h
rename : toolkit/components/remote/nsGTKRemoteService.cpp => toolkit/components/remote/nsGTKRemoteServer.cpp
rename : toolkit/components/remote/nsGTKRemoteService.h => toolkit/components/remote/nsGTKRemoteServer.h
rename : toolkit/components/remote/nsXRemoteService.cpp => toolkit/components/remote/nsXRemoteServer.cpp
rename : toolkit/components/remote/nsXRemoteService.h => toolkit/components/remote/nsXRemoteServer.h
extra : source : 28c7186745e3d5de5f44a72a81e0068cb23ce547
Adds build config and stubs for a windows implementation of the remote client
and server.
Differential Revision: https://phabricator.services.mozilla.com/D19074
--HG--
extra : rebase_source : f33e1ad19c1ed06fc79e017d62765a7632578258
extra : source : abd7789e9637c92978efcf745361b98c5abf847a
This code is only ever used from c++ so does not need to be an XPCOM component.
Broken out a single nsRemoteService that is responsible for choosing the server
implementation to use.
Differential Revision: https://phabricator.services.mozilla.com/D19067
--HG--
rename : toolkit/components/remote/nsDBusRemoteService.cpp => toolkit/components/remote/nsDBusRemoteServer.cpp
rename : toolkit/components/remote/nsDBusRemoteService.h => toolkit/components/remote/nsDBusRemoteServer.h
rename : toolkit/components/remote/nsGTKRemoteService.cpp => toolkit/components/remote/nsGTKRemoteServer.cpp
rename : toolkit/components/remote/nsGTKRemoteService.h => toolkit/components/remote/nsGTKRemoteServer.h
rename : toolkit/components/remote/nsXRemoteService.cpp => toolkit/components/remote/nsXRemoteServer.cpp
rename : toolkit/components/remote/nsXRemoteService.h => toolkit/components/remote/nsXRemoteServer.h
extra : rebase_source : 631ee45923c64acde92e23c155cbbbbc7a1d9c4d
The addition of the Carbon.h include to CreateAppData.cpp is to ensure that
The OSX API headers are used before conflicting symbols are declared in the
mozilla namespace.
Differential Revision: https://phabricator.services.mozilla.com/D16718
--HG--
rename : toolkit/xre/nsCommandLineServiceMac.cpp => toolkit/xre/nsCommandLineServiceMac.mm
extra : moz-landing-system : lando
When the updater is disabled toolkit/mozapps/update/common is not traversed as
part of the build. But toolkit/mozapps/update/common/commonupdatedir.cpp is
included in the toolkit/xre build regardless and GetInstallHash is used. This
makes nsXREDirProvider.cpp able to find the header that defines it.
Differential Revision: https://phabricator.services.mozilla.com/D16582
--HG--
extra : moz-landing-system : lando
Currently nsAppRunner is responsible for choosing or creating a profile to use
at startup. It then has to create a reset profile if necessary and lock the
selected profile directories. But these latter things are done in different
places of the selection code and done in different ways, sometimes we delay
while trying to get the lock, sometimes we don't.
This patch moves the profile selection part of the code to its own function so
that then we only have to have one place that does the profile reset and
locking logic.
It makes a lot of sense to have the selection code live in the profile service.
It can use information from the database load to help make the choices and it
also means that we can expose the profile selection code through xpcom allowing
it to be easily automatically tested. It will also be more important for future
patches for the dedicated profiles feature.
Differential Revision: https://phabricator.services.mozilla.com/D16116
--HG--
extra : moz-landing-system : lando
Razvan Maries
Kris Maglione
Emma Malysz
Molly Howell
Mihai Alexandru Michis
Mike Shal
Toshihito Kikuchi
Aaron Klotz
shindli
Brindusan Cristian
Ciure Andrei
Andreea Pavel
Mike Hommey
Kirk Steuber
Dave Townsend
Haik Aftandilian
arthur.iakab
Noemi Erli
Coroiu Cristina
Csoregi Natalia
Daniel Varga