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
We aren't intending to write to window.status here.
MozReview-Commit-ID: 7BRfgsO9NDr
--HG--
extra : rebase_source : 80bab7028668edd2f699b7ebe5b1ca1f6fb5e0a8
The behavior of ::BrowserTabsRemoteAutostart() shouldn't change, meaning that every result remains the same. The new getter can be accessed by JS through Services.appinfo.multiprocessBlockPolicy
MozReview-Commit-ID: 62PpbeJcMCI
