This commit:
- removes sendRpcMessage, which was unused;
- removes the CPOW argument to sendAsyncMessage, broadcastAsyncMessage, and
sendSyncMessage;
- removes the aIsSync argument used internally to distinguish sendRpcMessage
and sendSyncMessage;
- removes CPOW tests;
- updates the few remaining callsites that use more than 2 arguments in
sendAsyncMessage for the removal of the cpows argument.
Differential Revision: https://phabricator.services.mozilla.com/D71514
Before 1496578, URIFixup::keywordToURI used to do a synchronous IPC call to be
able to access search engines from the content process. Consumers of URIFixup
didn't care. Bug 1496578 moved the IPC messaging to the callers, in particular
nsDocShell, but assumed nsDocShellLoadState wasn't loading from content.
It looks like in some cases it does, so this adds another sync IPC call for
GetFixupURIInfo.
The total numer of sync IPCs should not change from before Bug 1496578, URIFIxup
was just doing it internally, while now it happens at the call point.
Note the long term plan would be for these docshell objects callers to just
handle URIs, while the UI code should do fixup.
Bug 1375244 tracks the removal of these sync IPC messages.
Differential Revision: https://phabricator.services.mozilla.com/D70607
--HG--
extra : moz-landing-system : lando
It seems that all the warnings caused by the GPU sandbox have been fixed, and
the transparent window issue was resolved in D61370.
Hopefully there are no further complications and this can stay landed.
Differential Revision: https://phabricator.services.mozilla.com/D18876
--HG--
extra : moz-landing-system : lando
This patch introduces `nt::VirtualQuery` which consumes only ntdll's functions
to reduce dependency in `MMPolicy` on kernel32.dll. With this, `MMPolicy` still
depends on kernel32.dll, that will be solved by a coming patch.
Differential Revision: https://phabricator.services.mozilla.com/D68342
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
TabGroup never really made any difference in which thread something go
dispatched to. This was the intended use, but development of TabGroups
with abstract main threads never made it that far. The good thing is
that thish makes it safe to also remove to the SystemGroup and instead
switch all SystemGroup dispatches to dispatches to main thread.
Timers for setTimeout and workers were the sole users of wrapped and
throttled event targets, that those throttled queues have been moved
to the BrowsingContextGroup and are now accessed explicitly.
The SchedulerEventTarget has been removed, since there are no longer a
separate event target for every TaskCategory. Instead a
LabellingEventTarget has been added to DocGroup to handle the case
where an event is dispatched do DocGroup or when an AbstractThread is
created using a DocGroup. This means that we'll actually label more
events correctly with the DocGroup that they belong to.
DocGroups have also been moved to BrowsingContextGroup.
Depends on D67636
Differential Revision: https://phabricator.services.mozilla.com/D65936
--HG--
extra : moz-landing-system : lando
To be able to remove SystemGroup, NS_ReleaseOnMainThreadSystemGroup
needs to have its dependency on SystemGroup removed. Since all
releases using SystemGroup would've released on the main thread anyway
we can safely replace NS_ReleaseOnMainThreadSystemGroup with
NS_ReleaseOnMainThread.
Depends on D64390
Differential Revision: https://phabricator.services.mozilla.com/D67631
--HG--
extra : moz-landing-system : lando
This patch introduces `nt::VirtualQuery` which consumes only ntdll's functions
to reduce dependency in `MMPolicy` on kernel32.dll. With this, `MMPolicy` still
depends on kernel32.dll, that will be solved by a coming patch.
Differential Revision: https://phabricator.services.mozilla.com/D68342
--HG--
extra : moz-landing-system : lando
When the GPU sandbox is enabled, access to most of the filesystem is blocked.
The GPU process uses a directory, "%profiledir%/shader-cache", to cache
compiled shared for performance reasons. Not allowing access to that directory
results in a HUGE performance backslide when the sandbox is turned on.
Differential Revision: https://phabricator.services.mozilla.com/D67893
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
No need for temporaries, we can just construct the object in place.
Depends on D69829
Differential Revision: https://phabricator.services.mozilla.com/D69830
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
No need for temporaries, we can just construct the object in place.
Depends on D69829
Differential Revision: https://phabricator.services.mozilla.com/D69830
--HG--
extra : moz-landing-system : lando
Mostly a matter of:
rg -l '\->LoadingPrincipal' | xargs sed -i 's/->LoadingPrincipal/->GetLoadingPrincipal/g'
And then clang-format. But I tweaked manually nsHttpChannelAuthProvider (move
the variable where it's used, don't take a useless strong ref),
AddonContentPolicy (move the declaration of the variable to the if condition),
and BackgroundUtils (same).
Differential Revision: https://phabricator.services.mozilla.com/D69828
--HG--
extra : moz-landing-system : lando
When marshaling a11y calls from the content process, there are quite a lot of cross-thread QueryInterface calls (ipc::mscom::Interceptor::QueryInterfaceTarget).
Some of these are for special COM interfaces like IAgileObject and IFastRundown, which we could just special case in Interceptor::QueryInterface like we do for INoMarshal.
However, it seems there are a lot of other interfaces being queried and it's not clear why.
This patch adds a new HandlerProvider method: IsInterfaceMaybeSupported.
This allows implementations to indicate when there are interfaces which they definitely don't support, allowing the call to be answered without a cross-thread call.
Differential Revision: https://phabricator.services.mozilla.com/D69285
--HG--
extra : moz-landing-system : lando
We add a flag 'HasStoragePermission' in the LoadInfo. This flag
represents whether the loading document, for docuemnt loads, or the
loading resource has the storage permission. And this flag would only
get updated in the parent process when opening the channel.
Differential Revision: https://phabricator.services.mozilla.com/D67466
--HG--
extra : moz-landing-system : lando
This wasn't useful cross-platform.
ATK was the only consumer of this and it now uses ProxyAccessible::ChildAtPoint.
This also means the related aNeedsScreenCoords functionality in PDocAccessible::AccessibleAtPoint is no longer needed and has thus been removed.
Finally, this renames PDocAccessible::AccessibleAtPoint to PDocAccessible::ChildAtPoint for consistency with Accessible::ChildAtPoint now that the functionality is mirrored.
Differential Revision: https://phabricator.services.mozilla.com/D67987
--HG--
extra : moz-landing-system : lando
Also adds missing includes in some files, these were previously only transivitely
included through mozilla/TypeTraits.h.
Differential Revision: https://phabricator.services.mozilla.com/D68561
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
For performance reasons, during launch this information is passed directly
to the child through the SetXPCOMProcessAttributes call
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
Previously, we only called AddTargetPeer() in
GeckoChildProcessHost::PerformAsyncLaunch() if the target process was not
sandboxed.
In the refactoring, the "else" clause was missed due to confusing CPP macros,
and now AddTargetPeer() is always called for non-plugin children.
This patch restores the old behavior of only calling AddTargetPeer() for non-
sandboxed processes.
Differential Revision: https://phabricator.services.mozilla.com/D67136
--HG--
extra : moz-landing-system : lando
This patch extends shared memory freezing to support the use case where
the parent process retains write access for incremental updates, while
other processes receive read-only access.
Note that, while some OSes allow independent read-only and read/write
capabilities for the same object, all we have on Android is an operation
that prevents future write mappings. Therefore, this allows an existing
writeable mapping to be retained, but if that is unmapped then even the
parent process can't re-create it.
As with freezing, the read-only restriction may not be enforceable if
the recipient process isn't adequately sandboxed (e.g., on Linux, if it
can use /proc/self/fd to reopen the inode for writing).
Differential Revision: https://phabricator.services.mozilla.com/D67187
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
The fork server is not launched as expected with the
preference. This patch fix the issue.
Differential Revision: https://phabricator.services.mozilla.com/D65930
--HG--
extra : moz-landing-system : lando
Remove old content sandbox code paths that allowed the sandbox to be started
later during content process startup when the SetProcessSandbox() message was
received from the parent process. This older way of starting the sandbox was
still in the tree to support WebReplay which is now being removed. With this
fix, content processes always use the "earlyinit" sandbox startup like the
RDD and GMP processes.
Differential Revision: https://phabricator.services.mozilla.com/D64968
--HG--
extra : moz-landing-system : lando
Before this patch, PSM would register content type handlers to handle certain
certificate types. This was an easy way to install a client certificate after
generating a key with <keygen>, but keygen has been removed. This was also an
easy way to install root certificates, but that's actually a considerable
security risk. We kept this functionality for so long because it was the only
way to add a 3rd-party root certificate to Fennec's certificate store. Now that
Fennec is EOL, we can remove it. (Fenix will need a way to trust 3rd party root
certificates, but the path forward there is to implement the enterprise roots
feature for Android.)
Differential Revision: https://phabricator.services.mozilla.com/D66118
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
We were using the wrong Accessible method to get the level. We also need to swap IPDL methods to use the right one.
Differential Revision: https://phabricator.services.mozilla.com/D65645
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
Dictionary iteration under Python 3 is in an inherently unpredictable order, and while we try to keep DEFINES ordered through the use of OrderedDicts, if at any point we populate DEFINES directly or indirectly while iterating through the contents of a non-ordered dictionary, the order of the DEFINES (and therefore the contents of the output Makefile) will be nondeterministic as well. This patch makes a number of changes to ensure that we only ever populate DEFINES in a deterministic fashion. (Note that in Python 3.7 and later, the built-in dict class actually has deterministic ordering, so these changes are technically only necessary until our minimum Python version becomes 3.7.)
Differential Revision: https://phabricator.services.mozilla.com/D66089
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
WalkHistoryEntries function gets called by nsSHistory::CloneAndReplaceChild
and nsSHistory::SetChildHistoryEntry recursively, so those have to be moved
into the parent process. This eliminates many sync IPC calls.
To facilitate transition to a new session history design,
we are mirroring mOSHE and mLSHE SH entries from docshell to browsing context.
Whenever we update those entries in docshell, we will also update those in BC,
and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D56201
--HG--
extra : moz-landing-system : lando
This patch partially implements `FileVersionInfoWin` and `base::FilePath` class of
Chromium sandbox so that a coming patch can use `base::win::OSInfo::Kernel32BaseVersion()`.
Differential Revision: https://phabricator.services.mozilla.com/D65744
Apps targeting SDK 29 are not allowed to open /dev/ashmem directly, and
instead must use NDK functions. Those functions are only available in
SDK 26 and higher, so we need this shim to use the functions if they
are available, else fallback to opening /dev/ashmem directly.
Differential Revision: https://phabricator.services.mozilla.com/D61012
--HG--
extra : moz-landing-system : lando
Given that we are going to add ContentBlockingAllowList in
CookieSettings, so CookieSettings will be responsible for more stuff than the
cookie behavior and cookie permission. We should use a proper name to
reflect the purpose of it. The name 'CookieSettings' is misleading that
this is only for cookie related stuff. So, we decide to rename
'CookieSettins' to 'CookieJarSettings' which serves better meaning here.
Differential Revision: https://phabricator.services.mozilla.com/D63935
--HG--
rename : netwerk/cookie/CookieSettings.cpp => netwerk/cookie/CookieJarSettings.cpp
rename : netwerk/cookie/nsICookieSettings.idl => netwerk/cookie/nsICookieJarSettings.idl
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We currently extract Document pointers from the old LoadInfo, and attach them to the new one, such that they aren't lost during serialization.
This moves us to setting them more directly from their original source, since the old LoadInfo is no longer reliable (and was only configured fully in the parent process).
Differential Revision: https://phabricator.services.mozilla.com/D64249
--HG--
extra : moz-landing-system : lando
We currently extract Document pointers from the old LoadInfo, and attach them to the new one, such that they aren't lost during serialization.
This moves us to setting them more directly from their original source, since the old LoadInfo is no longer reliable (and was only configured fully in the parent process).
Differential Revision: https://phabricator.services.mozilla.com/D64249
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
This removes `nsAutoPtr` usage from ipc/. security/ failed to build due to missing includes so I fixed that as well. IDB was using `ThreadLocal` from ipc which had a member changed to a `UniquePtr` so needed to be updated as well. localstorage was missing some includes.
Differential Revision: https://phabricator.services.mozilla.com/D63745
--HG--
extra : moz-landing-system : lando
We want to be able to send IPC messages from the translation in the parent. So
the simplest thing it move the top level actor parts of CanvasParent into
CanvasTranslator.
This patch also moves the canvas thread management parts out into a new
CanvasThreadHolder class and hopefully makes the lifecycle management of these
much more robust. This includes the use of a TaskQueue per CanvasTranslator to
manage serial processing on the canvas workers, instead of a boolean.
Differential Revision: https://phabricator.services.mozilla.com/D60887
--HG--
rename : gfx/layers/ipc/CanvasParent.cpp => gfx/layers/ipc/CanvasThread.cpp
rename : gfx/layers/ipc/CanvasParent.h => gfx/layers/ipc/CanvasThread.h
rename : gfx/layers/CanvasTranslator.cpp => gfx/layers/ipc/CanvasTranslator.cpp
rename : gfx/layers/CanvasTranslator.h => gfx/layers/ipc/CanvasTranslator.h
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
Previously we passed a potentially NULL pointer to
CrashReporterHost::FinalizeOrphanedMinidump() which always assumed it to be
non-NULL. This patch solves the issue but preventing the pointer from being
NULL and making CrashReporterHost::GenerateCrashReport() infallible. In the
case we fail to take a minidump the only visible effect will be that the
minidump ID will be empty, and existing code already expects and handles this
scenario correctly.
Differential Revision: https://phabricator.services.mozilla.com/D63179
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
The default method implementations cause problems when trying to
override them with different types in a direct call class.
For the `Recv__delete__` case there's a simple solution: omit it if
there are any arguments, because it doesn't make much sense to specify
arguments and then completely ignore them, and the no-arg case isn't a
problem for overriding.
Differential Revision: https://phabricator.services.mozilla.com/D62977
--HG--
extra : moz-landing-system : lando
Accessing StaticPrefs at xpcom-startup is too early to cause the
initialization of it. The preferences from user.js and profile are
not load yet. So, later, it would cause error of changing the value
of static prefs that is marked as mirroring once.
Differential Revision: https://phabricator.services.mozilla.com/D62866
--HG--
extra : moz-landing-system : lando
Apps targeting SDK 29 are not allowed to open /dev/ashmem directly, and
instead must use NDK functions. Those functions are only available in
SDK 26 and higher, so we need this shim to use the functions if they
are available, else fallback to opening /dev/ashmem directly.
Differential Revision: https://phabricator.services.mozilla.com/D61012
--HG--
extra : moz-landing-system : lando
This change adds new "remote backbuffer" logic when compositing without
HW acceleration on Windows (IE compositing through Cairo using the Win32
GDI)
A new piece of shared memory is created between the GPU process and the UI
process, and the GPU process sends requests to the UI process to first "borrow"
a properly-sized buffer to draw into, and then sends a "present" request to
tell the UI process to actually blit the buffer to the Win32 window.
This is needed for the GPU sandbox to work, since Windows rightly doesn't
allow the untrusted GPU process to directly draw the contents of a window
owned by the trusted UI process.
Differential Revision: https://phabricator.services.mozilla.com/D61370
--HG--
extra : moz-landing-system : lando
This change adds new "remote backbuffer" logic when compositing without
HW acceleration on Windows (IE compositing through Cairo using the Win32
GDI)
A new piece of shared memory is created between the GPU process and the UI
process, and the GPU process sends requests to the UI process to first "borrow"
a properly-sized buffer to draw into, and then sends a "present" request to
tell the UI process to actually blit the buffer to the Win32 window.
This is needed for the GPU sandbox to work, since Windows rightly doesn't
allow the untrusted GPU process to directly draw the contents of a window
owned by the trusted UI process.
Differential Revision: https://phabricator.services.mozilla.com/D61370
--HG--
extra : moz-landing-system : lando
All of these call sites were unnecessarily converting nsIPrincipal* => IPC::Principal => nsIPrincipal*.
Differential Revision: https://phabricator.services.mozilla.com/D62327
--HG--
extra : moz-landing-system : lando
From the documentation:
" While this interface is almost exclusively used with non-blocking streams, it is not necessary that nsIInputStream::isNonBlocking return true"
So we can't assume that a nsIAsyncInputStream is always non-blocking. Handle the case where it is.
Differential Revision: https://phabricator.services.mozilla.com/D61368
--HG--
extra : moz-landing-system : lando
Replace all implicit copies by moves, or explicit clone operations.
Fixed a bug in /home/simon/work/ipdl/ipc/ipdl/ipdl/lower.py _cxxConstRefType,
which caused the const accessor to miss const on its return type for a moveonly
struct member.
Removed unused using directives for SerializedStructuredCloneBuffer in ipdl files.
Differential Revision: https://phabricator.services.mozilla.com/D59742
--HG--
extra : moz-landing-system : lando
Replace all implicit copies by moves, or explicit clone operations.
Fixed a bug in /home/simon/work/ipdl/ipc/ipdl/ipdl/lower.py _cxxConstRefType,
which caused the const accessor to miss const on its return type for a moveonly
struct member.
Removed unused using directives for SerializedStructuredCloneBuffer in ipdl files.
Differential Revision: https://phabricator.services.mozilla.com/D59742
--HG--
extra : moz-landing-system : lando
I originally had this as a few patches, but the work to fix test
failures and get the whole thing into a complete working state
quickly tangled them up. Apologies for that. To summarize what's
going on here, however:
- We introduce two prefs: shutdown.fastShutdownStage and
shutdown.lateWriteChecksStage. The latter pref is set to 1, which
will leave the existing late write checking behavior unchanged.
However, we introduce this pref to make it simpler in the future
to bump the late write checks window earlier in the shutdown cycle.
- We introduce an AppShutdown class, which will house static methods
and a small amount of state for unifying some shutdown logic. Most
importantly, it will now manage the state for app initiated restarts,
as well as the logic for performing a safe fast shutdown.
- We refactored the existing restart code to call into the new
AppShutdown file, so that if we are configured to actually perform
a fast shutdown, we will be able to run the necessary restart logic
immediately before doing so. Previously, the restart logic occurred
later in the shutdown cycle than our late write checking, meaning
if we were to simply exit the process at that point in time, we
would never run the restart coe.
- Lastly, we updated two locations which called TerminateProcess and/or
_exit(0) to call into the AppShutdown method (DoFastShutdown).
Differential Revision: https://phabricator.services.mozilla.com/D59196
--HG--
extra : moz-landing-system : lando
It's no longer safe to try closing client_pipe_ when the I/O thread is
woken up with data from the child process, because that can race with the
launch thread doing its own close, and it's also unnecessary because of
that other close. See also bug 1607153 comment #2.
Differential Revision: https://phabricator.services.mozilla.com/D60627
--HG--
extra : moz-landing-system : lando
MacProcessLauncher overrides DoFinishLaunch from PosixProcessLauncher,
but doesn't call the superclass method, so CloseClientFileDescriptor is
never called on the channel.
Currently this doesn't cause any obvious problems, because the channel
object redundantly closes the fd when it first reads data from the child
process; however, that extra close is thread-unsafe and being removed in
bug 1607153.
Trying to fix bug 1607153 without this patch caused a number of test
suites to fail by timing out, probably because the extra copy of the
client (child) end of the pipe causes the server (parent) end to never
get an end-of-file or broken pipe error during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D61050
--HG--
extra : moz-landing-system : lando
This also adds an explicit warning when this happens so that the child processes don't crash without leaving a trace.
Differential Revision: https://phabricator.services.mozilla.com/D60650
--HG--
extra : moz-landing-system : lando
This patch does not change any of the *internals* of process management in
`GeckoProcessManager`, however it upgrades the interface in preparation for
such changes.
* We add a java equivalent to Gecko's `GeckoProcessType` enumeration;
* We add the `GeckoProcessType.Selector` class which will be used for
identifying running content processes;
* We update `ContentParent::MarkAsDead` to use `GeckoProcessType.Selector` for
indicating which process should be marked.
Differential Revision: https://phabricator.services.mozilla.com/D60539
--HG--
extra : moz-landing-system : lando
It's no longer safe to try closing client_pipe_ when the I/O thread is
woken up with data from the child process, because that can race with the
launch thread doing its own close, and it's also unnecessary because of
that other close. See also bug 1607153 comment #2.
Differential Revision: https://phabricator.services.mozilla.com/D60627
--HG--
extra : moz-landing-system : lando
We generate ByteBuf by rust bindgen, so we can drop StyleVecU8.
One potential follow-up is that we can merge this together with WrVecU8.
Differential Revision: https://phabricator.services.mozilla.com/D60328
--HG--
rename : ipc/glue/ByteBuf.h => ipc/glue/ByteBufUtils.h
extra : moz-landing-system : lando
We generate ByteBuf by rust bindgen, so we can drop StyleVecU8.
One potential follow-up is that we can merge this together with WrVecU8.
Differential Revision: https://phabricator.services.mozilla.com/D60328
--HG--
rename : ipc/glue/ByteBuf.h => ipc/glue/ByteBufUtils.h
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
Done with:
./mach static-analysis check --checks="-*, modernize-concat-nested-namespaces" --fix .
and then clang-format on the files
Differential Revision: https://phabricator.services.mozilla.com/D58217
--HG--
extra : moz-landing-system : lando
(This is a combination of 31 commits)
* Fix Linux compilation.
* Fix mac compilation.
* CI compile fixes.
* printf's size_t is %zu. %tu would be unsigned ptrdiff_t.
* No non-ref Maybe args.
* MOZ_CRASH for noreturn
* Handle implied texture sizes, rewrite comment stripping.
* Replace e.g. WebGLProgramInner with simpler webgl::ProgramKeepAlive.
* Bounce ValidateProgram call off driver.
* Uniform name length limit, cubemap fb-attach, non-array uniforms, undersized texImage views.
* alignas for uint8_t[sizeof(float)*N] pun buffers.
* CC fixes?
* Fill attrib0Active.
* Repair max-warnings limit.
* This is basically required in order for CI's logging to not explode.
* Don't cache WebGLMemoryTracker.
* Deleted prog/shader error, no texSubImage(null), client-side fingerprint resist for exts.
* Fix GetUniformIndices and MakeRangeFromView.
* CC Traverse base class from within derived class to fix leaking the world. :(
* PauseTransformFeedback
* TexImage video fastpath
* GetFragLocation for arrays
* Forbid BindBufferRange during TF
* Mark tests and fix RBAB query and test.
* Change(!) query deletion behavior to match spec.
* Mark conformance2/query/query.html failing for now.
* Implicitly EndQuery on DeleteQuery while spec is in flux.
* Fix error code for test.
* RAII LruPosition for WebGL context limit.
* Include std::list.
* Mark CompileResult and LinkResult.pending as false when retrieved.
* Hold strong-ref to NotLostData during Run<> to prevent LoseContext=>UAF.
* Don't assume GetUniformLocation(foo+'[0]') means foo is an array.
* Don't assume !mCanvasElement means !!mOffscreenCanvas.
* Handle composition while context-lost.
* All non-value-init members must be const or have inline init.
* Mark passing tests on Linux.
Depends on D54019
Differential Revision: https://phabricator.services.mozilla.com/D55739
--HG--
extra : moz-landing-system : lando
Splits WebGLContext into ClientWebGLContext and HostWebGLContext. The Client enables the JS-control of a WebGL context in a content procecss while the Host executes the WebGL graphics operations (via a WebGLContext that maintains much of the existing code) in the compositor process. At this point, the cross-process behavior is disabled -- this series of patches is an incremental step toward that final goal.
Differential Revision: https://phabricator.services.mozilla.com/D54018
--HG--
extra : moz-landing-system : lando
When a content or plug-in process crashes too early we haven't initialized the
CrashReporterHost for that process. This will cause the crash to be orphaned,
i.e. to miss most of its crash annotations. We added code to finalize those
crashes in bug 1282776 so that we wouldn't miss them entirely. This ensured
that crash reports would have both their .dmp and .extra files but the patch
failed to modify the code that notified various listeners about the crash
report's presence.
This changes always send the crash ID alongside the crash notifications, even
for orphaned crashes, so that listeners such as the content crash handler or
the test harnesses can always find the minidump and .extra file. Additionally
orphaned crashes are recorded in the CrashManager and in telemetry just like
normal crashes.
This also re-enables dom/ipc/tests/process_error.xul which failed frequently
because of this bug.
Differential Revision: https://phabricator.services.mozilla.com/D57634
--HG--
extra : moz-landing-system : lando
* Close leaking FDs of the fork server.
* Init the fork server before the initialization of the leak checker to avoid log files from taking lower file descriptor numbers.
Differential Revision: https://phabricator.services.mozilla.com/D57216
--HG--
extra : moz-landing-system : lando
Avoid crashing in IToplevelProtocol::GetMessageEventTarget() in DEBUG builds for messages that have been re-posted.
Differential Revision: https://phabricator.services.mozilla.com/D55861
--HG--
extra : moz-landing-system : lando
GetCurrentPhysicalThread and GetCurrentVirtualThread are, in practice,
identical, as the TLS override that GetCurrentVirtualThread depends on
is never actually set. This simply removes that and renames some things/
deletes some comments.
Rebased across https://hg.mozilla.org/mozilla-central/rev/3f0b4e206853
by Karl Tomlinson <karlt+@karlt.net>.
Differential Revision: https://phabricator.services.mozilla.com/D41247
--HG--
extra : moz-landing-system : lando
This patch adds DefaultURI which wraps MozURL which in turn forwards calls
to rust-url.
For the moment the added network.url.useDefaultURI is set to false by default.
The plan is to make this the default implementation for unknown URI types.
Differential Revision: https://phabricator.services.mozilla.com/D54748
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
This patch make changes of Gecko infrastrutures to run a fork server
process.
- ForkServerLauncher is a component, which creates a fork server
process at XPCOM startup.
- nsBrowserApp.cpp and related files have been chagned to start a
fork server in a process.
- Logging and nsTraceRefcnt were changed to make it work with the
fork server.
Depends on D46883
Differential Revision: https://phabricator.services.mozilla.com/D46884
--HG--
extra : moz-landing-system : lando
Class ForkServer and class ForkServiceChild are implemented. The
chrome process can ask the fork server process to create content
processes. The requests are sent by MiniTransceiver over a socket.
The fork server replys with the process IDs/handles of created
processes.
LaunchOptions::use_forkserver is a boolean. With use_forkserver being
true, the chrome process sends a request to the fork server instead of
forking directly.
Depends on D46881
Differential Revision: https://phabricator.services.mozilla.com/D46883
--HG--
extra : moz-landing-system : lando
MiniTransceiver is a simple request-reponse transport, always waiting
for a response from the server before sending next request. The
requests are always initiated by the client.
Depends on D46880
Differential Revision: https://phabricator.services.mozilla.com/D46881
--HG--
extra : moz-landing-system : lando
An instance of AppForkBuilder creates a new content process from
the passed args and LaunchOptions. It bascally does the same thing as
LaunchApp() for Linux, but it divides the procedure to two parts,
- the 1st part forking a new process, and
- the 2nd part initializing FDs, ENV, and message loops.
Going two parts gives fork servers a chance to clean new processes
before the initialization and running WEB content. For example, to
clean sensitive data from memory.
Depends on D46879
Differential Revision: https://phabricator.services.mozilla.com/D46880
--HG--
extra : moz-landing-system : lando
This patch make changes of Gecko infrastrutures to run a fork server
process.
- ForkServerLauncher is a component, which creates a fork server
process at XPCOM startup.
- nsBrowserApp.cpp and related files have been chagned to start a
fork server in a process.
- Logging and nsTraceRefcnt were changed to make it work with the
fork server.
Depends on D46883
Differential Revision: https://phabricator.services.mozilla.com/D46884
--HG--
extra : moz-landing-system : lando
Class ForkServer and class ForkServiceChild are implemented. The
chrome process can ask the fork server process to create content
processes. The requests are sent by MiniTransceiver over a socket.
The fork server replys with the process IDs/handles of created
processes.
LaunchOptions::use_forkserver is a boolean. With use_forkserver being
true, the chrome process sends a request to the fork server instead of
forking directly.
Depends on D46881
Differential Revision: https://phabricator.services.mozilla.com/D46883
--HG--
extra : moz-landing-system : lando
MiniTransceiver is a simple request-reponse transport, always waiting
for a response from the server before sending next request. The
requests are always initiated by the client.
Depends on D46880
Differential Revision: https://phabricator.services.mozilla.com/D46881
--HG--
extra : moz-landing-system : lando
An instance of AppForkBuilder creates a new content process from
the passed args and LaunchOptions. It bascally does the same thing as
LaunchApp() for Linux, but it divides the procedure to two parts,
- the 1st part forking a new process, and
- the 2nd part initializing FDs, ENV, and message loops.
Going two parts gives fork servers a chance to clean new processes
before the initialization and running WEB content. For example, to
clean sensitive data from memory.
Depends on D46879
Differential Revision: https://phabricator.services.mozilla.com/D46880
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
We'll use this method to expose additional information to the front-end for recovering from OOM.
Differential Revision: https://phabricator.services.mozilla.com/D54129
--HG--
extra : moz-landing-system : lando
When fuzzing, return an error instead of crashing in PrincipalInfoToPrincipal() for some error cases.
Differential Revision: https://phabricator.services.mozilla.com/D54215
--HG--
extra : moz-landing-system : lando
This function works on all GeckoProcessTypes, not just those for child
processes.
Differential Revision: https://phabricator.services.mozilla.com/D54375
--HG--
extra : moz-landing-system : lando
This function works on all GeckoProcessTypes, not just those for child
processes.
Differential Revision: https://phabricator.services.mozilla.com/D54375
--HG--
extra : moz-landing-system : lando
This patch adds a new field to the `plugin-crashed` event that holds the list
of additional minidumps associated with a crash report. The test
infrastructure is modified to use it which also fixes a race when processing
the .extra file. The reftest machinery has also been modified to take the new
field into account.
Differential Revision: https://phabricator.services.mozilla.com/D54107
--HG--
extra : moz-landing-system : lando
Previously, we created TextureD3D11 objects in the content process to back surfaces created for the plugin process. Those objects were then composited by the async ImageBridge. In order to remove Win32 kernel operations from content (including DX/GDI operations), this patch bounces the requests from content to the compositor process. The compositor process maintains 2 textures to be used for all plugin composition -- one for the plugin process and one for display. The plugin process can freely write to its texture and request composition when it is done, which triggers a blit to the display texture. This mirrors pre-existing behavior.
Differential Revision: https://phabricator.services.mozilla.com/D46086
--HG--
extra : moz-landing-system : lando
These operations report whether certain async plugin drawing modes are supported on the host architecture. They use kernel graphics operations to decide this so they need to be removed from the content process for sandboxing. We just bounce the requests to the gpu process (or main process on systems without a GPU process).
Differential Revision: https://phabricator.services.mozilla.com/D46085
--HG--
extra : moz-landing-system : lando
While the need for adding `mozilla::Vector` is self-evident, we also need
`std::vector` so that we can send some pre-existing telemetry data structures
that use it.
The new implementations are basically modified from the `nsTArray`
specializations. Note that the `mozilla::Vector` specialization does support
any type of allocator, so we still check for OOM failures in that case.
This patch also removes the specialization for `std::vector` that lives in
WebRTC in favour of the centralized implementation.
Differential Revision: https://phabricator.services.mozilla.com/D53085
--HG--
extra : moz-landing-system : lando
There are two issues here:
1. These error messages occur even during normal channel shutdown,
because that's tracked in the mozilla::ipc::MessageChannel layer,
which the ipc/chromium code can't access.
2. If we get this kind of error when the channel wasn't intentionally
closed, it almost certainly means that the other process crashed. In
that case, having error messages from a different process and a likely
unrelated subsystem just leads to confusion and misfiled bugs.
(Also complicating things: on Unix a closed channel often, but not
always, results in an end-of-file indication, which already isn't
logged; on Windows it's always a broken pipe error, which causes a much
larger amount of log spam.)
Bonus fix: the error that contains a fd number is clarified to avoid
having it mistaken for an error code.
Differential Revision: https://phabricator.services.mozilla.com/D52727
--HG--
extra : moz-landing-system : lando
Set the environment variable OS_ACTIVITY_MODE=disable on sandboxed Mac child processes.
Differential Revision: https://phabricator.services.mozilla.com/D49972
--HG--
extra : moz-landing-system : lando
shravanrn@gmail.com
Gijs Kruitbosch
Dorel Luca
Daniel Varga
Chris Peterson
Marco Bonardo
Christoph Kerschbaumer
Chris Martin
Andrea Marchesini
Cameron McCormack
Matt Woodrow
Bogdan Tara
Toshihito Kikuchi
Gabriele Svelto
Andreas Farre
Frederik Braun
Emilio Cobos Álvarez
Cosmin Sabou
Sylvestre Ledru
James Teh
Jeff Walden
Tim Huang
André Bargull
JulianWels
Oana Pop Rus
Razvan Maries
Bas Schouten
Jed Davis
Brindusan Cristian
Doug Thayer
Thinker Li
Kartikaya Gupta
Haik Aftandilian
JulianWels
Chris Fronk
Mihai Alexandru Michis
Noemi Erli
Dana Keeler
Ed Lee
Michael Froman
Ricky Stewart
Narcis Beleuzu
Eitan Isaacson
David Teller
Anny Gakhokidze
Aaron Klotz
Jonathan Kew
Mark Banner
James Willcox
Kershaw Chang
Jan Varga
Simon Giesecke
Andrew McCreight
Ciure Andrei
Coroiu Cristina
Eric Rahm
Bob Owen
Tom Ritter
Dave Townsend
Valentin Gosu
Arthur Iakab
shindli
Masatoshi Kimura
Csoregi Natalia
David Major
Nika Layzell
Jean-Yves Avenard
Perry Jiang
Boris Chiou
Dzmitry Malyshau
Andreea Pavel
Sebastian Streich
Nathan Froyd
Andi-Bogdan Postelnicu
Jeff Gilbert
David Parks
Boris Zbarsky
Olli Pettay
David Parks
Bobby Holley