This patch adds smart pointers to be used for initializing objects as C++11
"magic statics" -- that is, they are able to take advantage of C++11's
guarantee of thread safety during initialization by atomically constructing
both the smart pointer itself as well as the object being pointed to.
Unlike Static{Auto,Ref}Ptr, they have non-trivial constructors, though they
must still have trivial destructors to prevent emission of atexit calls.
The new classes use the new `MOZ_STATIC_LOCAL_CLASS` annotation which ensures
their instantiations are static locals and prevents non-trivial destructors.
Differential Revision: https://phabricator.services.mozilla.com/D40092
--HG--
rename : xpcom/base/StaticPtr.h => xpcom/base/StaticLocalPtr.h
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--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
Moves the trigger to gather total memory up about a hundred lines to the point before we bail on release so that it always triggers.
Differential Revision: https://phabricator.services.mozilla.com/D38249
--HG--
extra : moz-landing-system : lando
to make AutoJSAPI error reporting safe for worklets.
Parameter order matches xpc::ErrorReport::Init().
Depends on D34477
Differential Revision: https://phabricator.services.mozilla.com/D34478
--HG--
extra : moz-landing-system : lando
The previous error message suggested that this is an internal error message
pointing out a bad state in the XHR state machine, when in fact this is
a user error (calling `overrideMimeType()` or setting `responseType()` after
`send()`).
This commit improves and disambiguates the error messages, pointing out to
the user what they did wrong, like other browsers do.
Differential Revision: https://phabricator.services.mozilla.com/D37659
--HG--
extra : moz-landing-system : lando
I'd like to rely on always getting a stop event when the system recovers from a memory pressure situation. AIUI this already happens on Android platforms but not on Windows. This adds the stop event for Windows.
Differential Revision: https://phabricator.services.mozilla.com/D35679
This uses GetPerformanceInformation() to measure how much commit space is
available globally. Previously we relied on GlobalMemoryStatusEx() but in
spite of the function name the commit-space values it returns are
*per process* and thus unreliable. Available physical memory measurement has
also been removed since it was never used and we don't plan on using it
anytime soon.
Differential Revision: https://phabricator.services.mozilla.com/D35018
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
Change the Mac GMP process launch to include sandboxing params on the command line to allow the sandbox to be started earlier during GMP process launch. Content, extension, and RDD processes have already been changed to start the sandbox earlier.
Update GMPProcessParent to override GeckoChildProcessHost methods used to construct sandboxing parameters. Pass the plugin path as a sandbox parameter so that the sandbox rules can whitelist the plugin directory which is now read after the sandbox is enabled in the plugin process. On development builds, pass "testingReadPath" params so directories needed during automated tests can be whitelisted.
Update Mac sandboxing code to detect GMP sandbox params on the command line and enable the sandbox with additional arguments needed for early sandbox start.
Allow reverting to the old implementation by setting security.sandbox.gmp.mac.earlyinit to false.
Differential Revision: https://phabricator.services.mozilla.com/D34085
--HG--
extra : moz-landing-system : lando
When comparing compatibility versions we first compare the version part. If that
shows us to be a downgrade then we stop checking at that point. But we must also
stop checking if it shows us to be an upgrade since we don't need to check the
build IDs at that point. This also applies to the check for the app build ID.
This means that a newer version with an older build id will appear to be a
downgrade.
This is problematic for safe mode because when safe mode runs it sets the
compatibility version to "Safe Mode" (bug 1556831) to ensure that caches are
invalidated on next startup. On the next run the Firefox version is considered
as newer than "Safe Mode" so we would move on to comparing the build IDs. But
the Firefox build ID gets version compared to "" (since there isn't a build ID
part in "Safe Mode"). Since build ID's are larger than 32-bit numbers we trigger
bug 1556829 and the actual comparison depends on the value of the build ID
truncated to 32-bits. This seems to often be negative and so lower than the
apparent previous build ID causing us to think this is a downgrade.
Cue nfroydnj saying I told you so because if I'd written this as a more
traditional compare function as he suggested I probably would have caught this.
Differential Revision: https://phabricator.services.mozilla.com/D33702
--HG--
extra : rebase_source : bb506c4ba4d75a68976bb114015d53cd41b4d4c3
