So the remoting clients can know what the selected profile is before an attempt
to lock it is made we move the locking code to after the call to SelectProfile.
Differential Revision: https://phabricator.services.mozilla.com/D19420
--HG--
extra : moz-landing-system : lando
We cast the nsIToolkitProfileService to nsToolkitProfileService in a bunch of
places, might as well just hold that instead.
Differential Revision: https://phabricator.services.mozilla.com/D19414
--HG--
extra : moz-landing-system : lando
We cast the nsIToolkitProfileService to nsToolkitProfileService in a bunch of
places, might as well just hold that instead.
Differential Revision: https://phabricator.services.mozilla.com/D19414
--HG--
extra : moz-landing-system : lando
Previously we attempted to do this when XPCOM wasn't available so it always
failed to get the shell service. Instead set a flag telling us to do it later
when we choose the old default profile.
Also includes a block of code to attempt to fix the issue for existing nightly
users, this can be removed before betas.
Differential Revision: https://phabricator.services.mozilla.com/D18596
--HG--
extra : moz-landing-system : lando
Fixes leak where the return value of GetManifestContents in updater.cpp is not freed
Fixes leak where the return value of get_quoted_path in updater.cpp is not freed
Fixes leak in nsUpdateDriver.cpp ApplyUpdate
With these leaks fixed the UI tests that stage updates can run on Linux asan
Differential Revision: https://phabricator.services.mozilla.com/D17910
--HG--
extra : moz-landing-system : lando
Bug 730495 broke them by moving the code to another directory without
moving the corresponding #define, but it also fixed why this was
disabled in some configurations so we can now just enable when
MOZ_MEMORY is defined (jemalloc used).
Differential Revision: https://phabricator.services.mozilla.com/D18049
--HG--
extra : moz-landing-system : lando
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
This stops the use of some win32k calls during start-up that will fail and in
some cases cause a crash.
It also moves the MITIGATION_DYNAMIC_CODE_DISABLE to be enabled after start-up.
This is required because the hooks to fake the user32 and gdi32 initialization
are applied as the DLLs load and the dynamic code disable blocks that.
ProcessTypeRequiresWinEventHook was added when attempting to turn on win32k
lockdown for GMP processes. Having a less specific, but globally accessible,
function will make it more useful while applying win32k lockdown to other
process types.
Recently we use GDK_BACKEND to enable/disable Wayland backend. That's good for testing but bad for distro deployment.
When GDK_BACKEND is set it's propagated to child processes which may not support wayland thus they fail to run. Also when GDK_BACKEND=wayland is set Firefox fails to start when Wayland backend is not available.
To allow easy deployment let's use a specific MOZ_ENABLE_WAYLAND env which means to use a default available GTK backend (x11 or wayland) and don't fail when Wayland is missing.
Differential Revision: https://phabricator.services.mozilla.com/D17607
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
Under WOW64, the SysWOW64 directory is the effective system directory. A flag
has been added (ModuleTrustFlags::SysWOW64Directory) representing this
directory, and we now grant this the same trustworthiness as
ModuleTrustFlags::SystemDirectory.
Depends on D16013
Differential Revision: https://phabricator.services.mozilla.com/D16160
--HG--
extra : moz-landing-system : lando
In order to help unify DLL timings across machines with different performance
characteristics, this change collects the load duration of xul.dll.
Because xul.dll is always loaded, it can serve as a control value for DLL load
times.
Differential Revision: https://phabricator.services.mozilla.com/D16012
--HG--
extra : moz-landing-system : lando
This patch measures the duration of module loads and passes it up to
UntrustedModulesManager where, in later patches, it will be consumed by
telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D16011
--HG--
extra : moz-landing-system : lando