ipc/glue/ProtocolUtils.cpp:84:20: error: 'return' will never be executed [-Werror,-Wunreachable-code-return]
return IPCResult(false);
This error is a regression from bug 1778860.
Differential Revision: https://phabricator.services.mozilla.com/D189082
This adds a small function that concatenates the args (because not
only does the BSD `setproctitle` take a single string, but also the
Linux kernel code that implements `/proc/{pid}/cmdline` won't allow the
"arguments" to extend past their original length unless it's a single
string), and connects it to the fork server.
Differential Revision: https://phabricator.services.mozilla.com/D187635
The major changes:
* Instead of importing `base::ReadFileToString`, which is used only to
determine if a `/proc` pseudo-file contains more than a certain number
of characters, we simply `read` enough to determine that information.
* Instead of importing `base::NoDestructor` and wrapping it around STL
containers, we simply `strdup` the strings we need to copy out of
the initial arg/env area. (In theory this could set off LSan if the
copied string later becomes unreachable, but in practice that doesn't
seem to happen, and it's easily fixable if that changes.)
* Chromium copies only the environment strings and allows the argv
strings to be overwritten; this may be safe for how they access the
command line arguments but it may not be for us, so this patch changes
it to copy all of the strings.
Differential Revision: https://phabricator.services.mozilla.com/D187634
This is `content/common/set_process_title_linux.cc` from Chromium git
revision 5df26a3c960c011f068cea1fa9bc5866aaaa8aa2. This patch includes
only the file and doesn't attempt to build it or modify it to work with
our codebase; future patches will do that.
`about:license` already includes `ipc/chromium/` as a location that may
include code covered by the Chromium license, so this shouldn't need any
additional license acknowledgements.
Differential Revision: https://phabricator.services.mozilla.com/D187633
Unnamed POSIX semaphores are not supported on macOS, nor is timed wait supported on
named POSIX semaphores. SysV semaphores have similar limitations.
Mach semaphores are one of the only clean ways to create unnamed, shareable semaphores
on macOS. As of bug 1734735, we now can transparently send the mach ports across to
other processes without much added code, overall making this implementation of Mach
semaphores fairly easy.
Differential Revision: https://phabricator.services.mozilla.com/D188429
Implement a mochitest confirming the stability of Firefox when the
file-picker crashes (patterned loosely off the existing geolocation
crash tests).
Differential Revision: https://phabricator.services.mozilla.com/D184723
When opening a new Windows file dialog, open it out-of-process if
possible. Fall back to opening it in-process if that fails. (This
behavior is configurable with a pref.)
Differential Revision: https://phabricator.services.mozilla.com/D180343
The IPC subsystem effectively owns IPC actors, and requires an explicit
call to `Close()` to destroy a toplevel actor: releasing the last RefPtr
doesn't cut it. Similarly, the UtilityProcessManager owns the utility
processes it creates, and one must explicitly call `DestroyProcess()`.
Handle both of these lifetime issues by using a custom meta-RefPtr for
WinFileDialogParent which will close the actor and kill the process upon
its final `Release()`.
Differential Revision: https://phabricator.services.mozilla.com/D180345
Create and implement a new top-level IPC protocol, `PWinFileDialog`,
using the primitives from bug 1833450 and the new sandboxing type from
the previous commit.
Again, this commit does not actually create any instances of the new
protocol; that will come in a later commit in this patchset.
Differential Revision: https://phabricator.services.mozilla.com/D180342
Create a new utility-process type for the sole use of out-of-process
instantiation of the Windows file dialog.
We do not sandbox this process type, as in certain test environments
sandboxing has been found to prevent the child process from interacting
with any other windows on the desktop -- including the parent process
window which it will need to assign as the parent of the file dialog.
Technically, no functional changes, as this commit adds no uses of this
type. (That will come later in the patchset.)
Differential Revision: https://phabricator.services.mozilla.com/D180341
Before this change, the shared memory region handle was stored in a
shared object, meaning that it needed to be cloned when serializing to
create an owned copy of the handle to serialize over IPC. As cloning a
file descriptor or HANDLE is fallible, this meant that serializing a
DataPipe could crash if file descriptors were exhausted.
This change pre-clones the file descriptors and closes the original
descriptor at creation, removing that fallible operation from DataPipe
serialization.
Differential Revision: https://phabricator.services.mozilla.com/D187683
This is not the ideal form of this API, but avoids unnecessary handle
cloning and the corresponding fallible calls in some situations. In the
future we still want to do something more like bug 1797039, which will
provide a proper separation of handles from mappings for shared memory
regions.
Differential Revision: https://phabricator.services.mozilla.com/D187682
Use MOZ_IPC_MESSAGE_LOG to filter GOODBYE_MESSAGE_TYPE messages.
Interpret MOZ_IPC_MESSAGE_LOG elements without the "Child" or "Parent"
suffix as a request to log both sides of the given protocol.
Differential Revision: https://phabricator.services.mozilla.com/D187167
Previously, the client authentication certificate selection dialog could show
up unexpectedly. Because it was modal, it would prevent user interaction with
the browser. It could even get in a state where the dialog couldn't be
interacted with, and neither could anything else, so the entire browser would
be locked and the user would have to quit and restart.
This patch associates a top-level outer content window ID (called "browserId"
in networking code) with each NSSSocketControl. When a peer asks for a client
authentication certificate, the NSSSocketControl can use the ID to find the
relevant tab and open a tab-modal dialog, which allows other browser UI to be
interacted with.
Some loads cannot be associated with browser tabs, and so the implementation
falls back to opening a window-modal dialog on the most recently active window.
This is still better than the previous implementation, since the dialog is
connected to a window rather than being its own separate dialog.
Differential Revision: https://phabricator.services.mozilla.com/D183775
Previously, the client authentication certificate selection dialog could show
up unexpectedly. Because it was modal, it would prevent user interaction with
the browser. It could even get in a state where the dialog couldn't be
interacted with, and neither could anything else, so the entire browser would
be locked and the user would have to quit and restart.
This patch associates a top-level outer content window ID (called "browserId"
in networking code) with each NSSSocketControl. When a peer asks for a client
authentication certificate, the NSSSocketControl can use the ID to find the
relevant tab and open a tab-modal dialog, which allows other browser UI to be
interacted with.
Some loads cannot be associated with browser tabs, and so the implementation
falls back to opening a window-modal dialog on the most recently active window.
This is still better than the previous implementation, since the dialog is
connected to a window rather than being its own separate dialog.
Differential Revision: https://phabricator.services.mozilla.com/D183775
