On the compositor we store animation values in a hash table and the hash is
the compositor animation id which is a unique id for each property respectively.
So we can get the corresponding animation value for the given property.
In this patch there are lots of duplicated code, but they will be removed in the
next patch.
MozReview-Commit-ID: 7EboVcculcg
--HG--
extra : rebase_source : 304ea80849af8af72a07437736041aeabbe47eeb
This replaces using file_util to open and unlink temporary files
(/dev/shm on Linux, $TMPDIR or /tmp otherwise) with the POSIX shm_open
API, or ashmem on Android (which doesn't implement shm_open).
glibc maps shm_open/shm_unlink to open and unlink in /dev/shm (as does
musl libc), so the Linux situation is mostly unchanged except we aren't
duplicating code from system libraries. Other OSes may (and some do)
use more efficient implementations than temporary files.
FreeBSD's SHM_ANON extension is used if available. Sadly, it's not
standard; it would make this patch much simpler if it were.
This patch changes the shm file names; they now start with "org.mozilla"
instead of "org.chromium" because the original Chromium code is mostly
gone at this point. When running as a Snap package, the required
filename prefix is added; other container/sandbox environments using
AppArmor to restrict the allowed filenames may need to be adjusted.
The shm names now include the creating process's pid, to allow
using sandboxing to prevent interfering with shm belonging to other
applications or other processes within the same browser instance.
MozReview-Commit-ID: 7PirIlcblh4
This adds an about:memory branch, "ipc-channels", which counts
cross-process IPC channels (ProcessLink, IPC::Channel) broken down by
the top-level IPDL actor name; these use OS resources which may be
limited (file descriptors on Linux and Mac). Intra-process use of IPC
(ThreadLink) is not counted.
The maximum channel count for each actor type is reported in another
branch, "ipc-channels-peak". This might be useful if there are
conditions that cause transient fd exhaustion, for example.
This patch also works around a problem where MessageChannel was trying
to register reporters too early in child processes, and failing.
MozReview-Commit-ID: CGEwny2ipcu
--HG--
extra : rebase_source : ad526f03bbef891f4474225a8e36a7ed9e3acdab
nsIURIWithPrincipal is currently used to retrieve the nsIPrincipal from a
BlobURL object. BlobURLProtocolHandler has a hashtable containing, for each
blobURL, a BlobImpl and its nsIPrincipal. This patch introduces
BlobURLProtocolHandler::GetBlobURLPrincipal() that retrieves the nsIPrincipal
from this hashtable.
This patch fixes also a bug in how the revocation of blobURLs is broadcasted to
other processes. This should be done immediately because each process creates
its own timer to revoke them after 5 seconds.
An important change is related to NS_SecurityCompareURIs() where, if 1 (or
both) of the 2 URIs to compare, is a revoked BlobURL, we will QI its URL to
nsIStandardURL and fail out at that point.
The current code is somewhat non-obvious to a first-time reader, and
OS_TEST is a bizarre thing anyway, since it's actually the name of the
CPU we're running on. We'd do well to minimize the use of OS_TEST.
Note that the complete nuking of the xptcall/md/unix/moz.build lines are
because we don't support OS X/x86 anymore.
There's a lot going on here, but it all fits under the idea of
being able to communicate about texture locking statuses
without spinning on IsReadLocked. This is a bit of a trade -
we could just always allocate/grab a texture from the pool,
which would put a smaller cap on the amount of time we can
possibly spend when a texture is locked. However, this eats
up more CPU and memory than waiting on the textures to unlock,
and could take longer, especially if there were a large number
of textures which we just need to wait for for a short amount
of time. In any case, we very rarely hit the case where we
actually need to wait on the sync IPC to the compositor - most
of the time the textures are already unlocked.
There is also an async IPC call in here, which we make before
flushing async paints. This just causes the compositor to
check whether the GPU is done with its textures or not and
unlock them if it is. This helps us avoid the case where we
take a long time painting asynchronously, turn IPC back on at
the end of that, and then have to wait for the compositor
to to get into TiledLayerBufferComposite::UseTiles before
getting a response. Specifically this eliminates several talos
regressions which use ASAP mode.
Lastly, there seem to be no other cases of static Monitors
being used. This seems like it falls under similar use cases
as StaticMutexes, so I added it in. I can move it into its own
file if we think it might be generally useful in the future.
MozReview-Commit-ID: IYQLwUqMxg2
--HG--
extra : rebase_source : 4f05832f51dae6db98773dcad03cb008a80eca6c
There's a lot going on here, but it all fits under the idea of
being able to communicate about texture locking statuses
without spinning on IsReadLocked. This is a bit of a trade -
we could just always allocate/grab a texture from the pool,
which would put a smaller cap on the amount of time we can
possibly spend when a texture is locked. However, this eats
up more CPU and memory than waiting on the textures to unlock,
and could take longer, especially if there were a large number
of textures which we just need to wait for for a short amount
of time. In any case, we very rarely hit the case where we
actually need to wait on the sync IPC to the compositor - most
of the time the textures are already unlocked.
There is also an async IPC call in here, which we make before
flushing async paints. This just causes the compositor to
check whether the GPU is done with its textures or not and
unlock them if it is. This helps us avoid the case where we
take a long time painting asynchronously, turn IPC back on at
the end of that, and then have to wait for the compositor
to to get into TiledLayerBufferComposite::UseTiles before
getting a response. Specifically this eliminates several talos
regressions which use ASAP mode.
Lastly, there seem to be no other cases of static Monitors
being used. This seems like it falls under similar use cases
as StaticMutexes, so I added it in. I can move it into its own
file if we think it might be generally useful in the future.
MozReview-Commit-ID: IYQLwUqMxg2
--HG--
extra : rebase_source : 3624ad04aa01dac1cd38efb47764dc3a8fbd5fbd
There's a lot going on here, but it all fits under the idea of
being able to communicate about texture locking statuses
without spinning on IsReadLocked. This is a bit of a trade -
we could just always allocate/grab a texture from the pool,
which would put a smaller cap on the amount of time we can
possibly spend when a texture is locked. However, this eats
up more CPU and memory than waiting on the textures to unlock,
and could take longer, especially if there were a large number
of textures which we just need to wait for for a short amount
of time. In any case, we very rarely hit the case where we
actually need to wait on the sync IPC to the compositor - most
of the time the textures are already unlocked.
There is also an async IPC call in here, which we make before
flushing async paints. This just causes the compositor to
check whether the GPU is done with its textures or not and
unlock them if it is. This helps us avoid the case where we
take a long time painting asynchronously, turn IPC back on at
the end of that, and then have to wait for the compositor
to to get into TiledLayerBufferComposite::UseTiles before
getting a response. Specifically this eliminates several talos
regressions which use ASAP mode.
Lastly, there seem to be no other cases of static Monitors
being used. This seems like it falls under similar use cases
as StaticMutexes, so I added it in. I can move it into its own
file if we think it might be generally useful in the future.
MozReview-Commit-ID: IYQLwUqMxg2
--HG--
extra : rebase_source : 67f6fee8b89933561a48e6f7f531b6969893a574
At the moment this isn't actually async because we immediately require
the pid and block on launch anyway. It also crashes the entire browser
on otherwise recoverable launch errors, because code that wants the pid
isn't set up to handle that operation failing.
MozReview-Commit-ID: 5favGu34QCv
--HG--
extra : rebase_source : 3c81c53e1eb8ead353ef3477ed3ceea0f5edcbbe
These are no longer providing useful information. There are still a
noticeable number of failures on Windows, but we've narrowed them down to
within SandboxBroker::LaunchApp.
MozReview-Commit-ID: 9srWLNZq1Wo
--HG--
extra : rebase_source : db44114a7623e75f9efd629046d2118748352ed1
This patch adds a new IPDL protocol PBackgroundLocalStorageCache. It is used by LocalStorageCache object to broadcast changes in local storage cache to other content processes. Each origin has its own PBackgroundLocalStorageCache, so now we can notify content processes that actually have a local storage cache for given origin. This greatly improves performance and reduces memory footprint especialy when local storage changes carry big strings and/or happen very quickly (before this patch all child processes were blindly notified).
PublishTarget calls Unlock on our LiveSetAutolock.
It's possible for GetInitialInterceptorForIID to fail after this point.
This will cause the failure cleanup code to run, which tries to call Unlock again.
However, the previous call to Unlock set mLiveSet to null, and Unlock previously didn't handle this case.
Now, unlock is a no-op (in release builds) if it's already been called.
MozReview-Commit-ID: 15ffXR6nKqc
--HG--
extra : rebase_source : bf072824f15f5574dd8afbedef82b795086d5fff
If GetInitialInterceptorForIID fails, the live set lock is not released in most cases, but the newly created Interceptor will be destroyed.
The Interceptor's destructor tries to acquire the live set lock again, but that causes a deadlock, since reentry is no longer allowed for a mutex after bug 1364624.
GetInitialInterceptorForIID now ensures the live set lock is always released on failure, thus preventing the deadlock.
MozReview-Commit-ID: z0Q7JLnJXQ
--HG--
extra : amend_source : 0b9837e5500754b5782e72337fc59b7904c5e29c
Currently, in order to retrieve supported clipboard formats
DataTransfer::CacheExternalClipboardFormats repeatedly makes the same calls to
clipboard->HasDataMatchingFlavors.
In the case when aPlainTextOnly == true only 1 call is made -
clipboard->HasDataMatchingFlavors(kUnicodeMime, ...), and when
aPlainTextOnly == false we have 1 call made for every member of the list
{ kCustomTypesMime, kFileMime, kHTMLMime, kRTFMime, kURLMime, kURLDataMime,
kUnicodeMime, kPNGImageMime } - a total of 8 calls.
We can see that in nsClipboardProxy::HasDataMatchingFlavors, there is a call to
ContentChild::GetSingleton()->SendClipboardHasType.
So when aPlainTextOnly == true, we will have 1 sync message, and when
aPlainTextOnly == false, we will have 8 sync messages.
With the proposed solution, in DataTransfer::CacheExternalClipboardFormats
we will only have 1 sync message regardless of the case because
GetExternalClipboardFormats() will retrieve all supported clipboard
formats at once.
MozReview-Commit-ID: CAmBfqB459v
--HG--
extra : rebase_source : 27f1b420f2613e6a747ed63762f1583ab71ba3e0
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
This replaces some old Chromium code that tries to minimally disentangle
an arbitrary file descriptor mapping with simpler algorithm, for several
reasons:
1. Do something appropriate when a file descriptor is mapped to the same
fd number in the child; currently they're ignored, which means they'll
be closed if they were close-on-exec. This implementation duplicates
the fd twice in that case, which seems to be uncommon in practice; this
isn't maximally efficient but avoids special-case code.
2. Make this more generally applicable; the previous design is
specialized for arbitrary code running between fork and exec, but we
also want to use this on OS X with posix_spawn, which exposes a very
limited set of operations.
3. Avoid the use of C++ standard library iterators in async signal safe
code; the Chromium developers mention that this is a potential problem in
some debugging implementations that take locks.
4. In general the algorithm is simpler and should be more "obviously
correct"; more concretely, it should get complete coverage just by being
run normally in a debug build.
As a convenient side benefit, CloseSuperfluousFds now takes an arbitrary
predicate for which fds to leave open, which means it can be used in
other code that needs it without creating a fake fd mapping.
MozReview-Commit-ID: EoiRttrbrKL
--HG--
extra : rebase_source : 336e0ba9f56dc80f7347dc62617b4ad1efea7e7e
This directory has a number of places where files unintentionally depend
on `#include`s and `using` directives and forward declarations in other
files in the same unified build group. Adding a file shifts the group
boundaries and exposes some of those bugs; this patch fixes them (but
there are others).
MozReview-Commit-ID: AqAOdnXniTn
--HG--
extra : rebase_source : ed6030785d9cc5cc0ea1a46707725472de1c0fa9
We were first allocating and mapping a virtual memory area using mach_vm_allocate
(similar to mmap with MAP_ANON) and then obtaining a shareable capability for the
underlying VM object using mach_make_memory_entry_64. However the memory mapping
is fragmented into multiple objects if it's over 128mb. Larger memory allocations
than 128mb weren't possible. To fix this, we are calling mach_make_memory_entry_64
with MAP_MEM_NAMED_CREATE. That will create a new memory object and return a port
for it.
MozReview-Commit-ID: 5LLiaqJx175
--HG--
extra : rebase_source : 7ac964a1093eaf8ee30f319f5d21132c5d884362
This function returns the transform value modified by both OMTA and APZC.
Note that the transform conversion code is almost the same as the code dropped
in https://hg.mozilla.org/mozilla-central/rev/415811f3804f .
MozReview-Commit-ID: HmsMQp3O4n4
--HG--
extra : rebase_source : ac3994359d646dedaa5ff2f664b20787be8a75f6
Same approach as the other bug, mostly replacing automatically by removing
'using mozilla::Forward;' and then:
s/mozilla::Forward/std::forward/
s/Forward</std::forward</
The only file that required manual fixup was TestTreeTraversal.cpp, which had
a class called TestNodeForward with template parameters :)
MozReview-Commit-ID: A88qFG5AccP
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This defines three flushing functions that flush different parts of the
WR pipeline. Using all three guarantees that everything sent to WR will
have been flushed. This is what we need to do in SyncWithCompositor to
ensure that it meets the API contract.
In addition, this patch updates the existing FlushRendering function to
use the new functions (no functional changes intended here).
MozReview-Commit-ID: GzxwpF4JT04
--HG--
extra : rebase_source : 1a8cf434d1280902906da257ae63751da7ffd114
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : a8840bd26f4b01b756ffa72345ababb625048550
This adds all the samples from the provided sample set to the CountHistogram's
storage, instead of just adding 1 sample of value 1. This change does not affect
code outside of GeckoView persistence since |AddSampleSet| is not used in other
places.
MozReview-Commit-ID: 9bE0M9dgrtE
--HG--
extra : rebase_source : c2147d084415518b02148daa83107045f2993c0f
This switches over to manually managing the locking in MessageChannel::Close
in order to avoid a deadlock on msvc opt builds. It has the added benefit of
avoid a superfluous lock/unlock pair.
--HG--
extra : rebase_source : f3b0ee5499bd75bc75b3d1fe44c0c7efd3063aee
This commit removes some mtime checking logic in ipdl.py that is made redundant
with make's logic to re-invoke ipdl.py when dependencies have changed.
MozReview-Commit-ID: FJuYIZv5uym
--HG--
extra : rebase_source : 5e250cd2dd57b8591db700a3d79ec36c88fa4dd4
This commit removes some mtime checking logic in ipdl.py that is made redundant
with make's logic to re-invoke ipdl.py when dependencies have changed.
MozReview-Commit-ID: FJuYIZv5uym
--HG--
extra : rebase_source : 9e11ead04bd69eb1f30160fdb15b8ac74b183f87
Instead of crashing the process inside Transition on a bad state transition,
propagate an error up the stack (and crash higher up).
MozReview-Commit-ID: JJmAeq6xSfe
--HG--
extra : rebase_source : caba8a53603f7b0ad841b657aa3d00e827e3c68c
ByteBuf is a new IPDL built in type, so I wrote a very basic test for
it, based on shmem.ipdl. It was added in bug 1379680.
MozReview-Commit-ID: 4tbnljpUqCh
--HG--
extra : rebase_source : 6f423d7d9cf132aba4498be96548684e551b8e2c
Bug 1443954 added some new syntax to using, but I noticed that there
was not very much existing test coverage, so I wrote a new test that
covers all of the possible cases.
MozReview-Commit-ID: JRgHCtXHDLZ
--HG--
extra : rebase_source : caacc05ae5b1de0841f73e5fdba4891bfc0ee4bf
Failing IPDL parser tests require that the error message is specified.
MozReview-Commit-ID: IGNTVAb5r0Q
--HG--
extra : rebase_source : 54e75ae8820f4e9ae2083b1f5382ff4151c8d59e
The IPDL parser now expects a valid message-metadata to be passed in,
even though we don't need it for parser tests. Fix this by creating
and specifying a blank one. This fixes a regression from bug 1348591.
MozReview-Commit-ID: HJ34mqBdUyP
--HG--
extra : rebase_source : d444e5346f40399f1f1cf71b3d86b6dc15a4b731
The ipc/ipdl/test/cxx/ subdirectory is only built when MOZ_IPDL_TESTS
is set, because it needs special code to be built into the
binary. ipdl/ should always be built, because it does not need special
support. This gating is already done in the ipc/ipdl/test/ directory,
so it shouldn't be done in ipc/ipdl/, because this stops us from
building it in a regular build.
MozReview-Commit-ID: Jpp0CeXEenR
--HG--
extra : rebase_source : 3dbb6a5c9b7f6ec8cbe9840bff240a63342ecd49
There are three things we want to be true:
a) If the child sends a large value and the parent can't allocate enough space
for it we use an infallible allocation so the parent dies with an OOM.
b) If a fuzzer generates (huge-length, small-data) we don't try to allocate
huge-length bytes; knowing that the read will fail.
c) No fuzzer-specific branches in the core IPC serialization code.
Finally, this makes (huge-length, small-data) consistent with other cases where
the data is potentially truncated: ReadParam returns false.
MozReview-Commit-ID: 6nDKrw5z4pt
--HG--
extra : rebase_source : 58372d29139e9545a6ed2852c7243affeab6fdb7
We can move this information into ProtocolState and save having two
virtual functions for every protocol. Moving some bits out of the
codegen'd IPC code is a nice bonus, though we keep the strange setup
where toplevel protocols have two mChannel member variables.
ProtocolName() is only used for producing error messages and annotating
crash reports. But examining actual crash reports that would have used
the result of ProtocolName() indicates that we can always tell what the
erroring protocol is due to the stack backtrace. So having this virtual
function around just provides duplicate information, and it takes up too
much space in the vtable besides. Let's get rid of it.
lower.py generates repetitious:
SetManager(...);
Register(...); // Or RegisterID.
SetIPCChannel(...);
calls, which are moderately sized, given that the above call sequence
requires virtual calls in several places. Instead of codegenning this
sequence, let's consolidate the sequence into IProtocol and change the
code generator to call into the consolidated function instead.
This function is only overriden in two places, both of which go away
after early beta is done. We shouldn't be paying for its vtable entry
after that point.
The reasoning here is the same as for the protocol register/lookup
functions: these functions are all basic functionality that should not
be overriden by subclasses.
This functionality is base functionality for top-level and non-toplevel
protocols; nobody overrides this stuff, so it's safe to move into
ProtocolState.
IProtocol, which is inherited by every generated IPDL protocol and every
concrete protocol implementation in-tree, has a number of virtual
methods that are only relevant when distinguishing between top-level
protocols (IToplevelProtocol) and managed protocols (everything else).
These virtual methods require pointers in every protocol's vtable, which
is wasteful, and it's also somewhat confusing that many methods exist
but don't really need to be overridable in any useful way.
Let's clean this up, by creating a ProtocolState class to hold methods
that solely differ between top-level protocols and everything else.
This commit does that work and moves Shmem-related methods into this
class as a proof that this can be done in a reasonable way.
This function is just pure bloat when it gets inlined, and it will
disappear on non-Nightly builds anyway. Make it MOZ_NEVER_INLINE so our
size statistics on Nightly are somewhat more reflective of our size
statistics on Release.
This replaces using file_util to open and unlink temporary files
(/dev/shm on Linux, $TMPDIR or /tmp otherwise) with the POSIX shm_open
API, or ashmem on Android (which doesn't implement shm_open).
glibc maps shm_open/shm_unlink to open and unlink in /dev/shm (as does
musl libc), so the Linux situation is mostly unchanged except we aren't
duplicating code from system libraries. Other OSes may (and some do)
use more efficient implementations than temporary files.
FreeBSD's SHM_ANON extension is used if available. Sadly, it's not
standard; it would make this patch much simpler if it were.
This patch changes the shm file names; they now start with "org.mozilla"
instead of "org.chromium" because the original Chromium code is mostly
gone at this point. When running as a Snap package, the required
filename prefix is added; other container/sandbox environments using
AppArmor to restrict the allowed filenames may need to be adjusted.
The shm names now include the creating process's pid, to allow
using sandboxing to prevent interfering with shm belonging to other
applications or other processes within the same browser instance.
MozReview-Commit-ID: 7PirIlcblh4
--HG--
extra : rebase_source : 550a0ab013429c29a57bde5c0e4593d9b426da8e
I've also manually verified that no other references to HANDLE_EINTR are
wrapping a close() in any less syntactically obvious way.
MozReview-Commit-ID: 3KkBwFIhEIq
--HG--
extra : rebase_source : 4e79a70b3be22a7721b6f85b19ee5a31c98df456
This is based on the current security/sandbox/chromium version of eintr_wrapper.h,
taken from upstream commit 937db09514e061d7983e90e0c448cfa61680f605.
I've edited it to remove some things that aren't relevant to us: the
debug-mode loop limit in HANDLE_EINTR, because we don't seem to be
having the problem it's meant to fix and it risks regressions, and
references to Fuchsia, which we don't (yet) support. I also kept the
original include guards (the file path has changed upstream).
What this patch *does* do is add IGNORE_EINTR and modernize the C++
slightly (using decltype instead of nonstandard typeof).
MozReview-Commit-ID: BO4uQL9jUtf
--HG--
extra : rebase_source : ab3343c6d93e0ce753859217a55af131a0c4ea68
This patch was reviewed in parts, however the intermediate states would not build:
Bug 1443954 - Part 3A: Strip pointers from the argument to WriteParam and WriteIPDLParam before selecting the ParamTraits impl, r=froydnj
Bug 1443954 - Part 3B: Move nsIAlertNotification serialization to the refcounted system, r=bz
Bug 1443954 - Part 3C: Move geolocation serialization to the refcounted system, r=bz
Bug 1443954 - Part 3D: Move nsIInputStream serialization to the refcounted system, r=baku
Bug 1443954 - Part 3E: Move BlobImpl serialization to the refcounted system, r=baku
Bug 1443954 - Part 3F: Correctly implement ParamTraits for actors after the ParamTraits changes, r=froydnj
We want to spin for faster response, but we only want to spin for a very short time.
If we're waiting for a while, we don't want to be burning CPU for the entire time.
Therefore, only spin for 30 ms, then fall back to waiting on an event.
MozReview-Commit-ID: ErAIwpsIqYz
--HG--
extra : rebase_source : b6ac024adb7853456fd06c4385cf32184c8aeca2
I missed this one in bug 1431404.
This condition is rare and does indicate a problem which breaks accessibility.
However, we aren't getting any closer to diagnosing this as a result of this crash, so it causes user pain without any gain to us.
MozReview-Commit-ID: GncQGeZckrV
--HG--
extra : rebase_source : b6670005d53bc6d0009f0b8b142c2ab837b7d2e7
The current code is a bit of a mess. This patch does the following.
- Changes the processing from backwards to forwards. This avoids the need for
all the `found` booleans, because if a flag is present multiple times, the
last one will naturally override.
- Tightens up the checking. It now doesn't use assertions, but instead returns
false if any of the options are missing arguments, or have malformed
arguments, or any of the mandatory flags are missing. (It assumes that
-appdir and -profile are optional.)
- Renames the loop variable `idx` as `i`.
- Changes `!strcmp(...)` to `strcmp(...) == 0`, because I find that clearer.
- Avoids a redundant nsCString when handling -appdir.
The patch also tweaks GeckoChildProcessHost::mGroupId, which was buggy. It
holds the appModelUserId argument, which XRE_InitChildProcess() always expects
is present in the command. But it's only set to a non-empty value in
InitWindowsGroupID(), which is only called for plugin processes. So in lots of
cases the appModelUserId argument was missing, and a different argument would
be interpreted as the appModelUserId argument (seemingly without noticeable ill
effect).
The patch changes things to mGroupId defaults to "-", which means it's always
present in the command.
Note: all this explains why the old code for ContentProcess::Init() started
processing from argument aArgc, instead of aArgc-1 as you might expect -- it
had to read one extra arg in order to see the argument following -appdir,
because XRE_InitChildProcess() was decrementing aArgc for the appModelUserId
argument even when that argument wasn't present. The new code for
ContentProcess::Init() doesn't have to read past aArgc-1 because the mGroupId
fix ensures the appModelUserId argument is always present.
MozReview-Commit-ID: 8a8k6ABYMgo
--HG--
extra : rebase_source : 70695125ee26e67af3337119f4dfc293a0dab74c
Once we've figured out that some task needs to be reposted, there's no
reason to continue scanning the list to find other tasks that need to be
reposted, since the logic in this function just requires one task that
needs to be reposted.
This code isn't blocking anything, but it's dead and I don't think we
have any plans to use it.
MozReview-Commit-ID: KBoEfLceDns
--HG--
extra : rebase_source : 1eee3d961e249939f02d4cc40a707739eb2a596a
We're not using named shared memory, and supporting only anonymous
shared memory allows using other backends that are more compatible
with preventing a process from accessing any shared memory it wasn't
explicitly granted (i.e., sandboxing).
Specifically: SharedMemory::Open is removed; SharedMemory::Create no
longer takes a name, no longer has the open_existing option which doesn't
apply to anonymous memory, and no longer supports read-only memory
(anonymous memory which can never have been written isn't very useful).
This patch also fixes some comments in what remains of SharedMemory::Create.
MozReview-Commit-ID: 4kBrURtxq20
--HG--
extra : rebase_source : f6b1fb2fc79b6e9cdd251b3d9041036c0be503f9
This deletes some dead code and removes a dependency on the shared
memory object's name, which will be removed in the next patch (and is
always empty in our usage).
MozReview-Commit-ID: 1ub0nLCBucO
--HG--
extra : rebase_source : 6a29261e00b89773a2f2ace47303d9d9842c089b
This remotes the APZInputBridge interface over the PAPZInputBridge
protocol in the case of the GPU process, and makes the GPU process'
main thread act as the APZ controller thread in that process. If
there is no GPU process we continue as before and the APZInputBridge
interface implementation is the concrete APZCTreeManager instance
in the UI process.
The main changes in this patch are moving all the code associated with
these messages out of APZCTreeManager{Parent,Child} and into
APZInputBridge{Parent,Child}. APZCTreeManagerChild now returns an
APZInputBridgeChild instance via InputBridge(), instead of returning
itself. The SetControllerThread call in the GPU process is also updated.
MozReview-Commit-ID: M4AaIW1Q0h
--HG--
extra : rebase_source : e5a8f14e23be34229fe80a47f6789d19b19e0a9f
They are not yet fully async because ContentParent::InitInternal calls
OtherPid(), which will block until the process is spawned. Deferring the calls
to OtherPid() will be a subject of a follow up patch.
MozReview-Commit-ID: 4TFkMpdQtRw
--HG--
extra : rebase_source : 3e7567679ae04aa4c04ea6f6c146e70417e7ce05
This will let us manipulate it from multiple threads in a future patch.
MozReview-Commit-ID: 2AOgho8SEX9
--HG--
extra : rebase_source : 49e7d82b38e6f7b7eb9f6cb7c61a2b41d34f2bdc
