The bulk of this commit was generated by running:
run-clang-tidy.py \
-checks='-*,llvm-namespace-comment' \
-header-filter=^/.../mozilla-central/.* \
-fix
Using g_slice_set_config() fails with newer glib because the slice allocator
now has a static constructor that runs when glib is loaded, consequently
emitting a noisy error message which confuses people into believing it's the
root of their problems.
The only way left to force the slice allocator to use "system" malloc (in
practice, jemalloc) is to set the G_SLICE environment variable to
always-malloc, and that needs to happen before glib is loaded.
Fortunately, the firefox and plugin-container executables don't depend on
glib. Unfortunately, webapprt does, so the problem remains for web apps
running through it. xpcshell and other executables that depend on libxul
directly (as opposed to loading it dynamically) are not covered either.
Using g_slice_set_config() fails with newer glib because the slice allocator
now has a static constructor that runs when glib is loaded, consequently
emitting a noisy error message which confuses people into believing it's the
root of their problems.
The only way left to force the slice allocator to use "system" malloc (in
practice, jemalloc) is to set the G_SLICE environment variable to
always-malloc, and that needs to happen before glib is loaded.
Fortunately, the firefox and plugin-container executables don't depend on
glib. Unfortunately, webapprt does, so the problem remains for web apps
running through it. xpcshell and other executables that depend on libxul
directly (as opposed to loading it dynamically) are not covered either.
There's now a blacklist in place for the tools that should be disabled, so we want to give another change for users with tools that are not blacklisted to test e10s.
They are kept around for the sake of the standalone glue, which is used
for e.g. webapprt, which doesn't have direct access to jemalloc, and thus
still needs a wrapper to go through the xpcom function list and get to
jemalloc from there.
On X11, when running firefox -p foo http://mozilla.org, and a window for another
profile is already open, the -p argument is ignored and a new tab or window is
opened in the unrelated session.
Previously, the equivalent firefox -p foo -remote openurl(http://mozilla.org)
would see that there is no window for the profile foo, complain about it, and
abort. If a window for the profile foo was open, however, a new tab or windows
would open in that session.
Here, we modify the behaviour such that firefox -p foo http://mozilla.org never
ignores the -p argument, and does the sensible thing depending on the context:
- if a window is already open for the profile, use that session.
- otherwise, open a new window for that profile.
When no -p argument is given, the behaviour is unchanged.
As RemoteCommandLine, which first attempts to open a connection with an existing
firefox, falls through when there is no existing firefox, the -p argument must be
kept in the command line. It turns out CheckArg didn't handle the case properly,
so fix this as well.
The changes in RemoteCommandLine otherwise match what used to be in
HandleRemoteArgument before bug 1080319.
