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
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
The command-line parameter used by nsEmbedFunctions.cpp is turned into
an nsIFile, and then said nsIFile is never used. Its last use was
deleted in bug 1407693, where we reworked how extra annotations were
done.
When Firefox runs we cache a number of things, JS, XUL, XBL, CSS etc. Whenever
a new build of Firefox runs against a profile we clear the cache to rebuild with
the new information.
On the first run of a profile where compatibility.ini doesn't exist (presumably
to cover the case of upgrading from a very old versions of Firefox, but also
affects new profiles) we attempt to clear the cache as well.
If any attempt to clear the cache fails we set a flag in compatibility.ini
telling us to clear the cache on next startup.
Unfortunately nsIFile.remove returns different error codes on different
platforms when the file in question already doesn't exist. So an attempt to
remove a cache that does't exist is counted as a failure on Windows and so the
cache will be cleared again on second run.
This change counts the file not found return code as counting as a success when
clearing the cache.
Differential Revision: https://phabricator.services.mozilla.com/D16224
--HG--
extra : moz-landing-system : lando
Adds some includes that are needed for functions used in nsUpdateDriver.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D16063
--HG--
extra : moz-landing-system : lando
shindli
Bob Owen
arthur.iakab
Martin Stransky
Kris Maglione
Aaron Klotz
Nathan Froyd
Sylvestre Ledru
Cosmin Sabou
Greg Tatum
Dragana Damjanovic
Carl Corcoran
Dave Townsend
Coroiu Cristina
Kershaw Chang
Andreea Pavel
Daniel Varga
Margareta Eliza Balazs
Ehsan Akhgari
Bogdan Tara