MozReview-Commit-ID: JDSKZLgij83

MozReview-Commit-ID: 1Ftlwl3MfrW

Several source files use DLL_PREFIX/DLL_SUFFIX defines, and they all
set them in moz.build using `DEFINES`. This is problematic for the WSL build
because the quoting gets lost somewhere between bash and cl.exe. This patch
makes them set globally in moz.configure with `set_define`. There was an
existing global `MOZ_DLL_SUFFIX` define that was only used in one place, so
that has been removed in favor of simply `DLL_SUFFIX`.

MozReview-Commit-ID: 4ZQiqMK8Dgu

--HG--
extra : rebase_source : f85cbb4b9e6dc69881f312182cd4e37985baf22e

Each protocol in IPDL has a bunch of autogenerated functions that
instantiate IPC::Message with various parameters.  Each of these
functions, then:

1) Pays the cost of calling malloc()
2) Setting up various parameters
3) Calling IPC::Message()

There's no reason that we should be duplicating 1) across all of these
autogenerated functions.  In step 2), several of the parameters we're
setting up are common across all or nearly all calls: the message
segment size is almost always zero, and we're always indicating that
IPDL-generated messages should be recorded in telemetry.

Instead of duplicating that code several thousand times, we can add a
small helper function that takes the only interesting parameters for an
IPDL message.  This helper function can then deal with calling malloc in
a single place and setting up the common parameters.  For messages that
require a custom segment size, we'll have to use the old scheme, but
such messages are uncommon.

The previous changes are not required for this scheme to work, but they
do help significantly, as the helper function (Message::IPDLMessage) can
now take four parameters, which ensures that its arguments are passed
solely in registers on Win64 and ARM.  The wins from this change are
also larger than they would be without the previous parts: ~100K on
x86-64 Linux (!)  and ~80K on ARM Android.

The current IPC::Message constructor takes a large number of arguments,
three of which--the nesting level, the priority, and the
compression--are almost always constant by virtue of the vast majority
of Message construction being done by auto-generated IPDL code.  But
then we take these constant values into the Message constructor, we
check them for various values, and then based on those values, we
perform a bunch of bitfield operations to store flags based on those
values.  This is wasted work.

Furthermore, for replies to IPDL messages, we'll construct a Message
object, and then call mutating setters on the Message object that will
perform even more bitfield manipulations.  Again, these operations are
performing tasks at runtime that are the same every single time, and use
information we already have at compile time.

The impact of these extra operations is not large, maybe 15-30K of extra
code, depending on platform.  Nonetheless, we can easily make them go
away, and make everything cleaner to boot.

This patch adds a HeaderFlags class that encapsulates all the knowledge
about the various kinds of flags Message needs to know about.  We can
construct HeaderFlags objects with strongly-typed enum arguments for the
various kinds of flags, and the compiler can take care of folding all of
those flags together into a constant when possible (and it is possible
for all the IPDL-generated code that instantiates Messages).  The upshot
is that we do no unnecessary work in the Message constructor itself.  We
can also remove various mutating operations on Message, as those
operations were only there to support post-constructor flag twiddling,
which is no longer necessary.

There's no need to be repeating 'IPC::Message::' prefixes or spreading
around more ExprVar calls than we need here.  Let's try to improve the
signal-to-noise ratio of this code by introducing a helper function to
inject some of the boilerplate for us.

_generateMessageConstructor takes a lot of `md.FOO`-style parameters,
which could be derived inside the function by simply passing `md`.
Especially with the upcoming changes to calculate things like reply-ness
of messages, sync-ness, etc, we'd be wanting to pass even more
parameters like `md.FOO`.  So let's just pass `md` in, and then we can
make all the necessary future changes in a single place.

Bug 1395952: Enhance telemetry for failed launch of Windows sandboxed process by process type/error code key. r=jimm, data-r=rweiss

Only one telemetry accumlation will occur for each key per session.

Backed out changeset fdffa51b68d1 (bug 1390488) for build bustage at ipc/glue/GeckoChildProcessHost.cpp:868: undefined reference to `CrashReporter::GetChildProcessTmpDir(nsIFile**)'. r=backout on a CLOSED TREE

The GPU process doesn't have the directory service enabled, so it can't find
a tmp dir to put its .extra files for crash reports. Even if we do enable the
directory service, we still don't get the correct "content process tmp dir" in
the GPU process, because the UUID baked into that folder is passed via the
preferences service, and that isn't initialized in the GPU process either.
Rather than unneccessarily initialize all this stuff in the GPU process just
to get one folder name, we can pass that folder name directly in the argv list.

See comments 12-19 on the bug for further discussion of the various solutions
attempted/explored.

MozReview-Commit-ID: 1sFg27hIe7S

--HG--
extra : rebase_source : 62ff819c5b03f642cd4b9af7c89c84b790397372

This function is very large and has many nested ifdefs. Without this cleanup
it was really hard to figure out where all I needed to add code.

MozReview-Commit-ID: IeA0AWW62Mn

--HG--
extra : rebase_source : a8447df42c60da79f1c982111c8f65bd0175f1de

Backed out changeset 8ee1f7aebd62 (bug 1245527)
Backed out changeset e6a5de8d1246 (bug 1245527)
Backed out changeset be63e73426b4 (bug 1245527)

MozReview-Commit-ID: AU22LgPh9iB

The GPU process doesn't have the directory service enabled, so it can't find
a tmp dir to put its .extra files for crash reports. Even if we do enable the
directory service, we still don't get the correct "content process tmp dir" in
the GPU process, because the UUID baked into that folder is passed via the
preferences service, and that isn't initialized in the GPU process either.
Rather than unneccessarily initialize all this stuff in the GPU process just
to get one folder name, we can pass that folder name directly in the argv list.

See comments 12-19 on the bug for further discussion of the various solutions
attempted/explored.

MozReview-Commit-ID: 1sFg27hIe7S

--HG--
extra : rebase_source : 78eb600a58fed45800b9df8303cc4d6898d96ae9

This function is very large and has many nested ifdefs. Without this cleanup
it was really hard to figure out where all I needed to add code.

MozReview-Commit-ID: IeA0AWW62Mn

--HG--
extra : rebase_source : a8447df42c60da79f1c982111c8f65bd0175f1de

The nsIU2FToken and its implementors are no longer needed; the soft token was
re-implemented into dom/webauthn/U2FSoftTokenManager.cpp during the WebAuthn
implementation. When the dom/u2f/ code changed to the implementation from
WebAuthn, the old synchronous version became dead code.

This patch removes the dead code.

MozReview-Commit-ID: 2yDD0tccgZr

--HG--
extra : transplant_source : %B3%96Te%E7%02%08%98%1A%B2%FA%1C%40%C4J%BC%B2%85j%81

Bug 1383816 - Adds IPC Read and Write methods for FocusTarget and NoFocusState structs and creates EmptyStructSerializer helper class; r=botond

Since NoFocusState is am empty struct used in the |mData| variant in
FocusTarget, we need to add a Reader and a Writer for IPC for NoFocusState so we
can properly read and write the |mData| variant. The NoFocusState Read and Write
methods do not read or write anything, since NoFocusState does not contain any
data. This is done by creating a helper class EmptyStructSerliazer and
inheritting from EmptyStructSerializer for the NoFocusState specialization.

The |Read| and |Write| methods for FocusTarget are updated by removing the read
and write code for the individual types of |mData| and instead makes use of the
IPC read and write methods for Variant.

MozReview-Commit-ID: 3159sp6FLek

--HG--
extra : rebase_source : ff82797c26abffbd8bbcc465dc40c621be3257d0

* VariantWriter construction switched to use aggregate initialization
* Call to AsVariant was inappropriately called via |paramType| when it should
  have been called via |mozilla|
* |Next::Read| call in VariantReader specialization was missing the |result|
  argument

MozReview-Commit-ID: Izany7iDX0k

--HG--
extra : rebase_source : 7387e72100c7d2ba8fcfd1e5a3b6d0ce6be6c740

MozReview-Commit-ID: 96el4jm6WBS

MozReview-Commit-ID: 9MS9svUAeYR

It's important that shmem creation/destruction messages be ordered
correctly with respect to other messages that use shmems. For example,
if we create a shmem with ID 10 and then send a message that
references shmem 10, then the creation message must be handled before
the referencing message. If shmem creation/destruction messages go in
a separate queue from other messages, this ordering may not be
preserved.

Leaving shmem creation/destruction unlabeled will give us the correct
ordering. Eventually, though, we'll need to provide a solution that
doesn't bottleneck the event queue.

MozReview-Commit-ID: 88MrslRrfnh

Since LinearHistogram and its descendants inherit ranges_ from
Histogram, and we wanted to replace the copying into a std::vec
for Histogram, the simplest approach seemed to just be to
precompute ranges for all histograms, exponential or otherwise.
This should have the added benefit of reducing the memory
footprint for those histograms, since they will benefit from the
deduplication work that the precomputing script already does.

MozReview-Commit-ID: JTV5Dej5ZIb

--HG--
extra : rebase_source : de942d54b3475be54c70d43d2fa8e772ee2e18c4

Bug 1398907: Handler path should be written using length of null-terminated string in bytes, not size of the buffer; r=eeejay

MozReview-Commit-ID: 64Zv3obsQie

--HG--
extra : amend_source : bddaf442ed1af677aac6d03417fa2afc754b07eb

The WebRequest API needs to know if a given window ID is at the top level, for
various reasons. It currently figures this out by mapping a channel's load
context to a <browser> element, which tracks its current top outer window ID.
But this is inefficient, and not friendly to C++ callers.

Adding the top window ID to the load info simplifies things considerably.

MozReview-Commit-ID: Fy0gxTqQZMZ

--HG--
extra : rebase_source : bb5b1e1b3294004ca5e713fc88c4e20652296e53

Certain types (such as Shmem and Endpoint types) cannot be copied, and need to
be moved when passed around. When used with MozPromises, that means that the
promise needs to be non-shareable, and the resolve functions need to use the
correct ref qualifiers.

MozReview-Commit-ID: Kt4WZNsDErK

--HG--
extra : rebase_source : 5a96f9844df1646482aa223edf5081de9d5fc976

Backed out changeset 0eb505a8ac7c (bug 1395329) for Windows static bustage in Interceptor.obj. r=backout

MozReview-Commit-ID: 7ZLzpH030Of

--HG--
extra : rebase_source : 24fd48eb72bcee18bbc75a670d0035362dbeb92d

Bug 1395840: Backed out changeset e7f2eaf99d46 on suspicion of breaking virtual buffers in a11y clients; r=backout

Bug 1383501: Move a crash annotation so that it does not mask a previous annotation with the same key; r=handyman

MozReview-Commit-ID: 9u7VTKDglrS

Bug 1383501: Restrict mscom::MainThreadRuntime crash annotations to chrome and content to avoid false-positive leakchecks in gpu process; r=bustage CLOSED TREE

--HG--
extra : rebase_source : df8afbd05f6743163710cb29b1dab18a7aeaed3a

MozReview-Commit-ID: 90mZpD1YqpV

--HG--
extra : rebase_source : 4a46872e1a89cabd43576b9437a93912185af4f5

MozReview-Commit-ID: DIOsFREuhxj

--HG--
rename : ipc/mscom/InterfaceRegistrationAnnotator.cpp => ipc/mscom/RegistrationAnnotator.cpp
rename : ipc/mscom/InterfaceRegistrationAnnotator.h => ipc/mscom/RegistrationAnnotator.h

Bug 1390143 - Generate the parent minidump synchronously to keep parent process's stack when creating paired minidumps. r=gsvelto

Bug 1360308 offloads IO operations from the main thread when we create paired minidumps.
This breaks the symmetry of paired minidumps: the thread stacks of the parent minidump
doesn't correspond to the thread stacks in the child minidumps and renders the parent
stack useless. This patch moves generation of the parent minidump back to the main
thread to keep the context of the parent process when creating paired minidumps. Child
minidump is still created asynchronously.

MozReview-Commit-ID: 9RmBAuXMPSX

Bug 1393589: Refactor NOPING marshaling into its own class, mscom::FastMarshaler, and use it with IGeckoBackChannel; r=jimm

MozReview-Commit-ID: 9osDoYcvtWV

--HG--
extra : rebase_source : 9ead42f1b0c79f11b15121274a996d33d7ad4830

Bug 1390652: Part 3 - Add proxy wrapper that passes its inner proxy through content as a blob; r=jimm

MozReview-Commit-ID: A4pAyiuJUlz

MozReview-Commit-ID: EucWtw0YeBI