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
`windowUtils.setCompositionRecording()` now returns a promise that is resolved
when the composition recorder is enabled (if given `true`) or when frames are
written to disk (if given `false`). To accomplish this, the
`WebRenderCompositionRecorder` now returns a `MozPromise` when writing frames
to disk begins that is resolved when that process finishes.
Differential Revision: https://phabricator.services.mozilla.com/D47300
--HG--
extra : moz-landing-system : lando
`windowUtils.setCompositionRecording()` now returns a promise that is resolved
when the composition recorder is enabled (if given `true`) or when frames are
written to disk (if given `false`). To accomplish this, the
`WebRenderCompositionRecorder` now returns a `MozPromise` when writing frames
to disk begins that is resolved when that process finishes.
Differential Revision: https://phabricator.services.mozilla.com/D47300
--HG--
extra : moz-landing-system : lando
Inside of nsDocShell::UpdateURLAndHistory, there are 4 sync IPC calls to
nsSHistory plus 1 static call, which contains at least one nsSHEntry::GetParent
sync IPC call. All of these calls can be moved inside of a new method
EvictContentViewersOrReplaceEntry on nsSHEntry, resulting in just 1 sync IPC
call.
Differential Revision: https://phabricator.services.mozilla.com/D32729
--HG--
extra : rebase_source : ad09a9061cd6fe8eb6796b2809ea191aceb3ac73
extra : source : 2cd5cd24763ff320719aedb2142a79822efd6de4
extra : histedit_source : fdc4f80cfd8807e46c2dc02e6ab82f2bd3acc391
Currently, nsDocShell::GetChildSHEntry calls 3 sync IPC calls on nsISHEntry,
and the method GetChildSHEntry only has one caller. By moving GetChildSHEntry
method to parent process for nsISHEntry, resulting in a new method
nsISHEntry::GetChildSHEntry, 3 sync IPC calls can be reduced to 1.
Differential Revision: https://phabricator.services.mozilla.com/D27633
--HG--
extra : rebase_source : 1e76a1b07d827b35bae7ed6acca25aa8732c9ed0
extra : source : 34d91f82faa36dd8d8ed721de365122d831f7b25
extra : histedit_source : 86592bc747d506c546ec660e57087e78b9719cf7
Inside of nsDocShell::OnNewURI there are 4 sync IPC calls
to nsSHistory that can be replaced with 1 sync IPC call
by adding a new method EnsureCorrectEntryAtCurrIndex to nsSHistory.
Differential Revision: https://phabricator.services.mozilla.com/D31539
--HG--
extra : rebase_source : 09d7738b2f2dc2334c8f6186e5918b9d0ea3e618
extra : source : 82a41bffcbbca24ad3e84b045d75e4cb01ae1445
extra : histedit_source : 96eb7d2dbed2ad8fe4cc2d37358ec2358f696442
In nsDocShell::LoadHistoryEntry method, when it gets called
from parent process, there are 13 sync IPC calls on nsISHEntry
that retrieve information from the session history entry and
create a doc shell load state object using the retrieved
information. By adding a new method 'CreateLoadInfo'on nsISHEntry,
inside of which the doc shell load state object will be
created (with appropriate data filled out) and returned,
we eliminate 12 sync IPC call, resulting in just 1 IPC call
to nsISHEntry::CreateLoadInfo.
Differential Revision: https://phabricator.services.mozilla.com/D26042
--HG--
extra : rebase_source : a4e1fa52932fd5caabb59bd133e9fbee7f4d0e4a
extra : amend_source : f4d9f01afac0337808ba347eb997ce83e6ae1488
extra : source : 6ad53b35c7b4be933a3db1e1d45fa3da8a57abad
extra : histedit_source : c08d0cebcc11a3a4f64d01566cb62d9a334a12ec
Currently, nsDocShell repeatedly calls nsISHEntry::GetChildAt and
nsISHEntry::RemoveChild in nsDocShell::AddToSessionHistory,
which results in twice as many IPC calls as the number of children
a session history entry has. Additionally, there is one extra
IPC sync call to nsISHEntry::AbandonBFCacheEntry after the loop.
With the proposed solution, there will only be 1 sync IPC call.
Differential Revision: https://phabricator.services.mozilla.com/D24978
--HG--
extra : rebase_source : ab98af417bcb28fdfcb1a115473b505fa8a70aa1
extra : source : 0270d6b952ffa1704690c777c55fcaed30125b38
extra : histedit_source : 9a031cb921ad8efa1bd96f7342e08337f3c0ca8a
Currently, nsDocShell repeatedly calls nsISHEntry::GetChildAt, which
results in as many IPC sync calls as the number of children
a session history entry has. Calling nsISHEntry::GetChildCount and
ChildSHistory::Index and incurs additional extra 2 sync IPC calls.
With the proposed solution, there will only be 1 sync IPC call.
Differential Revision: https://phabricator.services.mozilla.com/D24980
--HG--
extra : rebase_source : ffaaff5c9521fb4d3a53a85f4570bcb99f7317d1
extra : source : 3f4a092d8f6544a212ee8a80d9275ae68c6446d1
extra : histedit_source : b4166d997119092ba5657f9ca4216da62dc82d97
For Fission, the parent process needs to take an Accessible sent up from one content process and send it down to another content process, where it will eventually be returned to the client.
If sandboxing is enabled, we must use a PassthruProxy, and if the handler is enabled, the handler will marshal the interface.
Even though we strip out the handler, the handler still marshals using the aggregated standard marshaler, which uses a different clsid (CLSID_AggStdMarshal).
When unmarshaling to return to the client, we call GetObjRefSize.
This previously didn't know about the aggregated standard marshaler, so it failed, causing E_INVALIDARG to be returned to the client.
Now, we just handle these clsids in the same way.
Differential Revision: https://phabricator.services.mozilla.com/D51246
--HG--
extra : moz-landing-system : lando
This patch converts the certList attribute of nsITransportSecurityInfo
from nsIX509CertList to Array<nsIx509Cert>
Differential Revision: https://phabricator.services.mozilla.com/D48745
--HG--
extra : moz-landing-system : lando
This patch converts the certList attribute of nsITransportSecurityInfo
from nsIX509CertList to Array<nsIx509Cert>
Differential Revision: https://phabricator.services.mozilla.com/D48745
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
We could try to move the EnforcePendingTaskGuarantee() bit into
PeekIdleDeadline, but then we'd need to check HasReadyEvent() on
mDeferredTimersQueue and mIdleQueue before we possibly unlock the mutex under
PeekIdleDeadline, and it's not clear that that state cannot change once the
mutex is unlocked...
The EnsureIsActive() call at the end of GetIdleDeadlineInternal in the !aIsPeek
case only makes sense if there are in fact idle tasks available to run when
GetDeadlineForIdleTask is called, because otherwise it would incorrectly set us
active when we are not running any tasks.
Differential Revision: https://phabricator.services.mozilla.com/D49696
--HG--
rename : xpcom/threads/PrioritizedEventQueue.cpp => xpcom/threads/IdlePeriodState.cpp
rename : xpcom/threads/PrioritizedEventQueue.h => xpcom/threads/IdlePeriodState.h
extra : moz-landing-system : lando
We could try to move the EnforcePendingTaskGuarantee() bit into PeekIdleDeadline, but
then we'd need to check HasReadyEvent() on mDeferredTimersQueue and mIdleQueue
before we unlock the mutex and PeekIdleDeadline, and it's not clear that that
state cannot change once the mutex is unlocked...
The EnsureIsActive() call at the end of GetIdleDeadlineInternal in the !aIsPeek
case only makes sense if there are in fact idle tasks available to run when
GetDeadlineForIdleTask is called, because otherwise it would incorrectly set us
active when we are not running any tasks.
Differential Revision: https://phabricator.services.mozilla.com/D49696
--HG--
rename : xpcom/threads/PrioritizedEventQueue.cpp => xpcom/threads/IdlePeriodState.cpp
rename : xpcom/threads/PrioritizedEventQueue.h => xpcom/threads/IdlePeriodState.h
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.
Differential Revision: https://phabricator.services.mozilla.com/D41247
--HG--
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
* At this point our DLL blocking infra is complicated enough that I decided to
bite the bullet and move all of this code out of `mozglue/build` and into its
own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
receives a vector containing all saved records of loaded DLLs that happened
until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
any other non-`firefox` processes that do not have a launcher process
providing a loader API.
* We add some wide to UTF8 conversion functions.
Depends on D43157
Differential Revision: https://phabricator.services.mozilla.com/D43158
--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : browser/app/winlauncher/freestanding/LoaderAPIInterfaces.h => mozglue/dllservices/LoaderAPIInterfaces.h
rename : browser/app/winlauncher/freestanding/ModuleLoadInfo.h => mozglue/dllservices/ModuleLoadInfo.h
rename : browser/app/winlauncher/NtLoaderAPI.h => mozglue/dllservices/NtLoaderAPI.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
* At this point our DLL blocking infra is complicated enough that I decided to
bite the bullet and move all of this code out of `mozglue/build` and into its
own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
receives a vector containing all saved records of loaded DLLs that happened
until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
any other non-`firefox` processes that do not have a launcher process
providing a loader API.
* We add some wide to UTF8 conversion functions.
Differential Revision: https://phabricator.services.mozilla.com/D43158
--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
* At this point our DLL blocking infra is complicated enough that I decided to
bite the bullet and move all of this code out of `mozglue/build` and into its
own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
receives a vector containing all saved records of loaded DLLs that happened
until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
any other non-`firefox` processes that do not have a launcher process
providing a loader API.
* We add some wide to UTF8 conversion functions.
Differential Revision: https://phabricator.services.mozilla.com/D43158
--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
* At this point our DLL blocking infra is complicated enough that I decided to
bite the bullet and move all of this code out of `mozglue/build` and into its
own subdirectory, `mozglue/dllservices`.
* We delete the original `UntrustedDllsHandler` code which is now obsolete.
* We implement mozglue's `LoaderObserver`:
** When this observer registers itself with the launcher process API, it
receives a vector containing all saved records of loaded DLLs that happened
until that moment.
** This code handles profiler labels and stackwalking suppression.
** Once a load has completed, we either pass the load on to XUL for further
processing, or save it for later if XUL is not initialized yet.
* mozglue has its own `ModuleLoadFrame` implementation for the legacy blocklist.
* `DllServicesBase` is updated to support the new interfaces.
* We implement `FallbackLoaderAPI` for `plugin-container`, `xpcshell`, and
any other non-`firefox` processes that do not have a launcher process
providing a loader API.
* We add some wide to UTF8 conversion functions.
Differential Revision: https://phabricator.services.mozilla.com/D43158
--HG--
rename : mozglue/build/Authenticode.cpp => mozglue/dllservices/Authenticode.cpp
rename : mozglue/build/Authenticode.h => mozglue/dllservices/Authenticode.h
rename : mozglue/build/WindowsDllBlocklist.cpp => mozglue/dllservices/WindowsDllBlocklist.cpp
rename : mozglue/build/WindowsDllBlocklist.h => mozglue/dllservices/WindowsDllBlocklist.h
rename : mozglue/build/WindowsDllBlocklistCommon.h => mozglue/dllservices/WindowsDllBlocklistCommon.h
rename : mozglue/build/WindowsDllBlocklistDefs.in => mozglue/dllservices/WindowsDllBlocklistDefs.in
rename : mozglue/build/WindowsDllServices.h => mozglue/dllservices/WindowsDllServices.h
rename : mozglue/build/gen_dll_blocklist_defs.py => mozglue/dllservices/gen_dll_blocklist_defs.py
rename : mozglue/build/moz.build => mozglue/dllservices/moz.build
rename : mozglue/build/MozglueUtils.h => mozglue/misc/WinUtils.h
extra : moz-landing-system : lando
This is to get initial feedback/review.
PIdleScheduler.ipdl has the documentation about the basic architecture.
(v15)
Differential Revision: https://phabricator.services.mozilla.com/D45162
--HG--
extra : moz-landing-system : lando
We'd like to offer a way for developers to safely do asynchronous instantiations
of COM objects. This patch adds a static CreateInstance method to mscom::EnsureMTA
that facilitates this under certain conditions (as outlined in the comments).
To help ensure that this is as safe as possible, we return a MozPromise that,
once resolved, produces an AgileReference that may then be passed between
threads, and may then be resolved when a specific thread needs to access the
interface.
Differential Revision: https://phabricator.services.mozilla.com/D44519
--HG--
extra : moz-landing-system : lando
We want to ensure that the code being added in part 2 is only used when it is
reasonable and safe to do so. One way to ensure this is to add a check that the
desired CLSID is an in-process, thread-aware server.
Differential Revision: https://phabricator.services.mozilla.com/D44518
--HG--
extra : moz-landing-system : lando
This will help to catch changes that cause a loss of annotations without
affecting Release or Beta.
This also makes CrashReporterClient::InitSingleton return void as the previous
bool was ignored in all cases.
Differential Revision: https://phabricator.services.mozilla.com/D44642
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
Until now, AgileReference was not copyable because it could not handle the
copying of global interface table cookies. By moving the cookie into its own
reference counted object, we can enable copying on the AgileReference.
Differential Revision: https://phabricator.services.mozilla.com/D43616
--HG--
extra : moz-landing-system : lando
This patch provides us with utility functions that give us more specific
information about the current thread's MTA if so desired.
Differential Revision: https://phabricator.services.mozilla.com/D41852
--HG--
extra : moz-landing-system : lando
As part of the ongoing effort to port the nsIWebProgress events from
RemoteWebProgress / WebProgressChild to BrowserParent / BrowserChild, we need
to (de)serialize the nsITransportSecurityInfo instance across the IPC layer.
The existing code was calling `NS_SerializeToString` which has the overhead of
(a) allocating a buffer and also performing base64 encoding/decoding. This
patch adds `IPC::ParamTraits` implementations for `nsITransportSecurityInfo`,
`nsIX509Certificate`, and `nsIX509CertList` that (de)serializes the params
directly onto and off of the IPC message so that we don't go through the
overhead of allocating and encoding/decoding an additional buffer.
This (de)serialization will address the performance issues present in the
current implementation.
As a side effect, I also make nsITransportSecurityInfo a builtinclass XPCOM
interface, since the existing serialization code was assuming it was, there is
only one implementation, and it is in C++.
Differential Revision: https://phabricator.services.mozilla.com/D35090
--HG--
extra : moz-landing-system : lando
