Now that fields are packed nicely, we can take advantage of the
contiguous layout of POD fields and read/write all the POD fields of a
given size in a single read/write call. For many structs, this should
have little or no effect, but for large structs such as LoadInfoArgs,
this reduces the number of function calls by ~50%.
Differential Revision: https://phabricator.services.mozilla.com/D22001
--HG--
extra : moz-landing-system : lando
We're about to start depending on how the fields are packed in a future
patch, so we should add some compile-time checking that our assertions
are correct.
Differential Revision: https://phabricator.services.mozilla.com/D22000
--HG--
extra : moz-landing-system : lando
We're going to read and write sentinels slightly differently for
bulk-writing adjacent fields, so let's factor out some reusable code for
doing so.
Differential Revision: https://phabricator.services.mozilla.com/D21999
--HG--
extra : moz-landing-system : lando
This patch changes the layout of IPDL-defined structs to order the POD
members by decreasing size, which ensures everything is packed well.
This optimization is only applied to the internal representation; the
external interface (e.g. constructors) is entirely unchaged.
Differential Revision: https://phabricator.services.mozilla.com/D21998
--HG--
extra : moz-landing-system : lando
This patch computes an ordering for the fields of an IPDL structure decl
such that they are packed well in memory. We'll take advantage of this
ordering in future patches.
Differential Revision: https://phabricator.services.mozilla.com/D21997
--HG--
extra : moz-landing-system : lando
By allowing the creation of StrongWorkerRefs in the Canceling state we
ensure that IPC will not fail and lead to crashes.
Differential Revision: https://phabricator.services.mozilla.com/D21920
--HG--
extra : moz-landing-system : lando
This is needed to maintain full feature parity with the existing
nsIPrincipal serializer while switching to using the PrincipalInfo-based
one.
Depends on D14434
Differential Revision: https://phabricator.services.mozilla.com/D20854
--HG--
extra : moz-landing-system : lando
GMP shouldn't need them anyway, and this reduces the dependencies from the x86
build we need to package in the "i686" subdir.
Differential Revision: https://phabricator.services.mozilla.com/D19902
--HG--
extra : source : 72ef2d2e9429ddb00d423181e3f8c881db228889
extra : intermediate-source : 1481e243977a28f1e8bbc12641f9a44ecb0a3856
extra : histedit_source : 1eb8f04f329e2df8f92b85a884304fd89c616234
This patch assumes that "the build" places plugin-container.exe, xul.dll, and
their dependencies in the "i686" subdirectory of the aarch64 firefox package
directory.
Differential Revision: https://phabricator.services.mozilla.com/D19898
--HG--
extra : source : bcba2fa22c772ba7c17e0dbdb5a10e5bbfe900d6
extra : histedit_source : 4b7f79876b3e67d1c1c64d91e869c3ad1efc4913
This is needed to maintain full feature parity with the existing
nsIPrincipal serializer while switching to using the PrincipalInfo-based
one.
Depends on D20853
Differential Revision: https://phabricator.services.mozilla.com/D20854
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
This patch tries to move them to `ContentParent` instead.
`ProcessPriorityManagerImpl::ObserveContentParentCreated` could not be moved
due to using `do_QueryInterface` to cast from a `nsISupports` down to the
`ContentParent` object. This could be fixed to remove the interfaces entirely,
but I left that for a follow-up.
Depends on D20549
Differential Revision: https://phabricator.services.mozilla.com/D20550
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
This follows the naming convention of the related functions _splitClassDeclDefn() and _splitFuncDeclDefn().
Depends on D20056
Differential Revision: https://phabricator.services.mozilla.com/D20057
--HG--
extra : moz-landing-system : lando
Bug 1428984 caused a regression where ipdlc will emit (empty) method definitions for pure methods. C++ allows a pure member function to have a definition (in case a derived class wants to call a default implementation in the base class), but we don't want this for ipdl's generated code.
Differential Revision: https://phabricator.services.mozilla.com/D20056
--HG--
extra : moz-landing-system : lando
* Be sure to set mInitResult = S_OK when we've already done process-wide initialization;
* Don't bother checking for Win32 lockdown unless we're not in the parent process
Differential Revision: https://phabricator.services.mozilla.com/D20386
--HG--
extra : moz-landing-system : lando
nsSystemInfo is initialzied at first page load. Actually, content process uses
sync IPC to get Android OS information. But now, we can use Java code even if
on content process, so we should use JNI directly instead of sync IPC.
Also, nsSystemInfo still has unused extern android_sdk_version that is for
HoneyComp's DNS hack. So let's remote it.
Differential Revision: https://phabricator.services.mozilla.com/D20129
--HG--
extra : moz-landing-system : lando
* New topLevel loads get the nsILoadInfo.openerPolicy of the current top level document
* Parsing the Cross-Opener-Origin-Policy of a channel will update mLoadInfo.openerPolicy and this value will get propagated to the child process.
* SessionStore now checks nsIHttpChannel.hasCrossOriginOpenerPolicyMismatch (preffed off) and performs a process switch if needed
Differential Revision: https://phabricator.services.mozilla.com/D19000
--HG--
rename : toolkit/components/remotebrowserutils/tests/browser/browser_httpResponseProcessSelection.js => toolkit/components/remotebrowserutils/tests/browser/browser_httpCrossOriginOpenerPolicy.js
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
* New topLevel loads get the nsILoadInfo.openerPolicy of the current top level document
* Parsing the Cross-Opener-Origin-Policy of a channel will update mLoadInfo.openerPolicy and this value will get propagated to the child process.
* SessionStore now checks nsIHttpChannel.hasCrossOriginOpenerPolicyMismatch (preffed off) and performs a process switch if needed
Differential Revision: https://phabricator.services.mozilla.com/D19000
--HG--
rename : toolkit/components/remotebrowserutils/tests/browser/browser_httpResponseProcessSelection.js => toolkit/components/remotebrowserutils/tests/browser/browser_httpCrossOriginOpenerPolicy.js
extra : moz-landing-system : lando
The one exception is refcounted types, because std::move(RefPtr<T>) does not
coerce to T*, which is what the current IPC methods accept.
This does not rewrite all Recv/Answer methods to take advantage of move
semantics.
Differential Revision: https://phabricator.services.mozilla.com/D19669
--HG--
extra : moz-landing-system : lando
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
* New topLevel loads get the nsILoadInfo.openerPolicy of the current top level document
* Parsing the Cross-Opener-Origin-Policy of a channel will update mLoadInfo.openerPolicy and this value will get propagated to the child process.
* SessionStore now checks nsIHttpChannel.hasCrossOriginOpenerPolicyMismatch (preffed off) and performs a process switch if needed
Differential Revision: https://phabricator.services.mozilla.com/D19000
--HG--
rename : toolkit/components/remotebrowserutils/tests/browser/browser_httpResponseProcessSelection.js => toolkit/components/remotebrowserutils/tests/browser/browser_httpCrossOriginOpenerPolicy.js
extra : moz-landing-system : lando
Shmem sizes serialized in an ipc::ShmemCreated message should be sent as an
uint32_t rather than a size_t, as size_t is defined as different sizes in 64
and 32 bit builds. If the size isn't consistent, we won't be able to reliably
send this message between cross architecture processes.
Also, Shmem's have a limit of 32bit for their size anyway:
https://searchfox.org/mozilla-central/rev/e00ea598e52bbb35f8c45abf9c2eade17962bb5e/ipc/glue/Shmem.cpp#127
So this patch should not affect allocations of shmems.
Differential Revision: https://phabricator.services.mozilla.com/D18909
--HG--
extra : source : d7276bbcafafd5cb96ef498ef74629294483e002
extra : amend_source : 9e4b7721cfbef5f2caf34c22de106c3127628597
extra : intermediate-source : 57b88145a6357f2fd3d93a101952b22279a246f2
Implements the windows remove client and server based on the current remoting
code in nsNativeAppSupportWin.cpp. Makes the hidden window classname encode both
program name and profile name. nsNativeAppSupportWin is now just used for
setting up the console.
Differential Revision: https://phabricator.services.mozilla.com/D19076
--HG--
extra : source : 84e8066625fd72fdb1eb6eab85621ae842fe91b4
extra : amend_source : b698f986cce0ccfae29c04fcbe0d84a6c8605ab6
Implements the windows remove client and server based on the current remoting
code in nsNativeAppSupportWin.cpp. Makes the hidden window classname encode both
program name and profile name. nsNativeAppSupportWin is now just used for
setting up the console.
Differential Revision: https://phabricator.services.mozilla.com/D19076
--HG--
extra : rebase_source : 57d9dd30fe7df2dab104bdc15cf68467d3f56e91
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Alloc/Dealloc methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18131
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
This is a supplement to further increase coverage of IPC fuzzing and to fulfill support for Faulty on all platforms.
Differential Revision: https://phabricator.services.mozilla.com/D16888
--HG--
extra : moz-landing-system : lando
Launching processes takes enough time that we should avoid blocking the
parent process's IPC I/O thread for it; it's less bad for responsiveness
than blocking the main thread, but it's not good.
On Windows we need to use a dedicated thread, because the sandbox isn't
thread-safe and it asserts that the same thread is used for every
launch. Otherwise, a thread pool is used. (Or, in the Web Replay
middleman process, where there isn't enough of XPCOM for any of this,
launching the actual content processes remains on the I/O thread.)
Depends on D18011
Differential Revision: https://phabricator.services.mozilla.com/D8946
--HG--
extra : moz-landing-system : lando
In order to enable asynchronous launch, destruction of
GeckoChildProcessHost (and its subclasses) has to be delayed until after
launching (or anything else that might be made asynchronous in the
future) has completed, to prevent use-after-free. However, there are
other dependencies on process hosts always being destroyed on the I/O
thread, so refcounting would be difficult to use.
Instead, GeckoChildProcessHost now may not be destroyed directly, but
must go through a method that handles the scheduling.
There are also some minor cleanups to the affected headers (removed
duplicate access modifiers, and made PluginProcessParent final).
Depends on D18010
Differential Revision: https://phabricator.services.mozilla.com/D18011
--HG--
extra : moz-landing-system : lando
This file has text-substitution placeholders that aren't part of normal
C++ syntax; they were broken by auto-inserted whitespace. This patch
restores the original formatting and protects them from further change.
Differential Revision: https://phabricator.services.mozilla.com/D18010
--HG--
extra : moz-landing-system : lando
The total size of an IPC inputStream message must be less than 1mb. When we
compose the message for the multiplex stream, each sub stream collaborates with
its own size, deciding if it's better to be a pipe stream (IPCRemoteStream) or
a full serialized one.
Differential Revision: https://phabricator.services.mozilla.com/D18543
--HG--
extra : moz-landing-system : lando
This includes deleting several unused functions. Our own code does a better job
of using the preferred platform APIs for random numbers.
Differential Revision: https://phabricator.services.mozilla.com/D18120
--HG--
extra : moz-landing-system : lando
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.
Before this patch, IPCStream was an union containing IPCRemoteSteam or an
InputStreamParamsWithFds. Now InputStreamParamsWithFds is renamed IPCStream and
IPCRemoteSteam is one of the possible InputStreamParams structs.
Before this set of patches, the decision of exposing the stream as a pipe was
centralized in IPCStreamUtils, based on the total expectation size of the IPC
message. This triggers issues when multiplex inputStreams contain something
that cannot be sent as a pipe (IPCBlobInputStream, for instance), or something
that it's better to do not set as a pipe (nsFileInputStream), together with
memory streams (nsStringInputStream), which could make the IPC message greater
then what accepted (1mb).
These patches move the "pipe vs non-pipe" choice into the single inputStream
implementation.
This removes all .flake8 files except for the one at the root of the repo.
Instead we use the new 'per-file-ignores' config introduced in 3.7. To ignore
specific errors in a subdirectory, add a line like this to the root .flake8:
[per-file-ignores]
path/to/subdir/*: E100, F200, ...
The reasons for this change are:
1. Unblock flake8 blacklist (bug 1367092).
2. Simplify configuration and code.
3. Encourage more consistent styling.
4. Improve performance.
5. Greater editor consistency.
Differential Revision: https://phabricator.services.mozilla.com/D18354
--HG--
extra : moz-landing-system : lando
This bumps flake8 to version 3.7.5.
This also ignores the new lint rules that were added in the new versions.
These rules are de-marked via comment so we know that they should be enabled at
some point (as opposed to the other rules that are (presumably) ignored
intentionally.
Differential Revision: https://phabricator.services.mozilla.com/D18353
--HG--
extra : moz-landing-system : lando
This is handy when performing process swaps, as it provides useful & important
information to parent-process callers.
Depends on D15608
Differential Revision: https://phabricator.services.mozilla.com/D15609
--HG--
extra : moz-landing-system : lando
Andreea Pavel
Alex Gaynor
Dorel Luca
Sylvestre Ledru
Andrea Marchesini
David Major
Chris Pearce
Valentin Gosu
Csoregi Natalia
Jan Varga
Coroiu Cristina
Nathan Froyd
Masatoshi Kimura
Yaron Tausky
Luke Wagner
Gurzau Raul
Nika Layzell
Cosmin Sabou
Boris Zbarsky
Ciure Andrei
Aaron Klotz
Ryan Hunt
Oana Pop Rus
Chris Peterson
Makoto Kato
Razvan Maries
Mike Hommey
Bogdan Tara
Michael Froman
Andreas Farre
Christoph Kerschbaumer
Noemi Erli
Jonathan Kingston
shindli
Dave Townsend
Christoph Diehl
Nathan Froyd
Jed Davis
Bob Owen
Ehsan Akhgari
Andrew Halberstadt
Gijs Kruitbosch