There's some reorganization of the code in aboutSupport to support displaying Windows XP as a string without needing to be localized, as this will require an uplift to Aurora.
MozReview-Commit-ID: IqLjEIKq0VI
OS X shared memory is currently set up in XRE_InitChildProcess and torn
down in XRE_ShutdownChildProcess. The current location of shared memory
shutdown is vulnerable to races from outstanding shared memory requests
from ImageBridge threads; if we request a new shared memory segment from
an image bridge thread after shared memory has been shutdown, we will
crash.
Despite its name, XRE_ShutdownChildProcess doesn't actually perform all
shutdown steps; it merely notifies the main run loop that it's OK to
exit, which eventually returns control to XRE_InitChildProcess. Inside
XRE_InitChildProcess, then, is where cleanup of the content process
actually happens, and where shared memory shutdown needs to be.
This makes a function call in XRE_InitChildProcess for the child process that
currently exists in XREMain::XRE_mainStartup for the parent process.
This allows signals that jprof uses to be sent to a child process to
profile that child process.
MozReview-Commit-ID: CeWnYl4LJyA
The original changeset that is being backed out had comment:
Bug 1023941 - Part 5: Loader hook to redirect the missing import.
The changes made in bug 1023941 were to work around the fact that with VS2013, msvcr120.dll imports kernel32!GetLogicalProcessorInformation, which is not available on Windows XP SP2.
In VS2015, the GetLogicalProcessorInformation requirement has moved into concrt140.dll (concurrency runtime), which we don't use.
So, now that our build infra is building with VS2015, we can remove the hooking and static runtime linking required to get the VS2013 fix to work.
In addition we need to do that to be able us to link the Chromium sandbox code into firefox.exe and get it to build and run with both VS2015 and VS2013.
MozReview-Commit-ID: 1tlXaYJ8dHH
--HG--
extra : rebase_source : 49b216e34fc5c77af96df1f67ee44c46d5368bfe
This removes all of the e10s-related prompting code, including:
- doorhanger offering to opt-in into e10s
- pref and telemetry probe used to measure the number of users who remained opted-in
- dialog that shows up when unchecking the e10s checkbox saying that a tab will open, requesting feedback
- tab opening requesting feedback
- all related strings
The checkbox in the preferences window remains (nightly/aurora only), as well as the message saying that e10s requires a restart.
The e10s accessibility doorhanger remains. and chrome://browser/skin/e10s-64@2x.png remains too because it's also used in the a11y doorhanger.
MozReview-Commit-ID: aOdvnbeHOa
--HG--
extra : rebase_source : e89cc42dddcb376bece435138611b364d3477fa8
End state is Waldo's original patch, which so far has been the only
version that compiles on VS2015.
MozReview-Commit-ID: FCOaEvMqYB4
--HG--
extra : rebase_source : 2ee6e5ec7578b2dedb2f57a0f6df4ce50e191d98
Since the minidump path can be overridden programmatically in the chrome
process, using that path as the base for .extra files won't work since content
is unaware of it.
This patch changes everything to use the temp path when MOZ_CONTENT_SANDBOX is
not defined or when sandboxing is disabled via pref. It also moves the derivation
of the content temp path out of exception context on Windows and Mac, as I
found out that those functions touch the heap.
I also noticed that xpcshell is not sandbox-aware when utilized as a parent
process. I've filed bug 1257098 to take care of that, but this patch includes a
hack for the immediate term.
MozReview-Commit-ID: 3SIB5Nihqxh
--HG--
extra : rebase_source : f4f83c4474f12ececa34e9dda68fc19abc56a899
