Previously we used the MozPromise interface for calling an async-message over
IPC with a reply. Unfortunately, MozPromise processes the reply asynchronously,
potentially allowing other IPC messages to be processed before the `->Then`
callback is processed.
In the original CreateWindow patch I tried to work around this by setting the
target of the `->Then` callback to be StableStateEventTarget. This worked,
however as it isn't safe to run scripts etc. in the stable state, we instead
tried to exit the nested event loop immediately after the runnable ran, and then
performed processing of the reply.
Unfortunately, this bug exposed a problem with that design. If we have multiple
nested event loops then we cannot guarantee that we'll exit the nested event
loop immediately after recieving the `->Then` callback, which meant that we
could still process other IPC messages before we processed the CreateWindow
reply.
The fix to this was to add a new API to allow passing callbacks directly into
IPC send methods, ensure that those callbacks are called in IPC order, and
fully process the CreateWindow reply in the callback, rather than waiting for
the nested event loop to exit.
MozReview-Commit-ID: D6zaMJRxhXd
Don't retrieve parent display by DetectDisplay().
Utilize MOZ_GDK_DISPLAY when available, when it's missing query DISPLAY env variable for X11 only builds and standard gtk_init() for Wayland enabled builds.
MozReview-Commit-ID: 9yebsISeNjc
It's easy to mess up the scoping so that (a) the label is pushed and then
immediately popped, and/or (b) the string doesn't live long enough. It's also
easy to do a utf16-to-utf8 conversion unnecessarily when the profiler is
inactive. This patch splits that macro into three new ones that are harder to
mess up.
- AUTO_PROFILER_LABEL_DYNAMIC_CSTR: same as current.
- AUTO_PROFILER_LABEL_DYNAMIC_NSCSTRING: for nsCStrings.
- AUTO_PROFILER_LABEL_DYNAMIC_LOSSY_NSSTRING: for nsStrings.
Early in the startup the channel creation might fail,
in nsStringBundle load and any further attempts are prevented which
leads to broken ocaization support for the process. Let's wait until
the child process learns about the chrome URLs registered on the parent
side with the preloads.
Since ContentChild itself may be created before the observer service is
started, we cannot create an observer to simply listen for the
xpcom-shutdown event. Thankfully we do not need to do anything special
upon receiving the event -- we just need to know if it has been fired
when we called RecvSetXPCOMProcessAttributes. As such, this patch
creates a canary using ClearOnShutdown. If the canary is cleared, then
we know xpcom-shutdown has been issued, and we should abort the
initialization process.
fixup
It has been observed on nightly and beta that the compositer thread
fails to shutdown gracefully due to lingering references. From what
can be determined, it appears as if the content process references
are what are keeping it alive. The shutdown of CompositorBridgeChild
was altered because a top level protocol was added above it in a
previous change in bug 1365927. This protocol tree is ultimately
what is keeping the thread alive. As such, this patch adds an
explicit shutdown of the protocol, to ensure it gets released in a
timely manner.
This change will be backed out if it appears to have no effect on
the crash rate in nightly 57.
These are all easy cases where an nsXPIDLCString local variable is set via
getter_Copies() and then is only used in ways that nsCStrings can also be used
(i.e. no null checks or implicit conversions to |char*|).
In every case the patch trivially replaces the nsXPIDLCString with an
nsCString. (Also, there are a couple of unused nsXPIDLCString variables that
the patch simply removes.)
I don't bother to label the runnables in the parent process being fired by
VisitedQuery, as we are not planning to perform scheduling in the parent process
if I remember correctly. It would be possible to label those runnables as well.
MozReview-Commit-ID: EosNOu62fEV
Moves IsDevelopmentBuild(), GetRepoDir(), and GetObjectDir() out of
SandboxSettings because they also need to be used by ExtensionProtocolHandler
to do security checks on developer builds as a result of how developer builds
rely on symlinks to the repo dir from system extension directories.
Remove the Linux-implementation of GetRepoDir() and GetObjectDir()
because the Linux content sandbox implementation and the
ExtensionProtocolHandler checks don't need them.
MozReview-Commit-ID: KwBFUnh6Cml
Without this patch, all remote process types share a process name of
"Web Content". With this patch, specific names are added for "file",
"extension", and "webLargeAllocationTypes", with the default of "web"
left as the default "Web Content".
This patch also eliminates undocumented b2g-era legacy logic that had a
notion of whether it's acceptable to override the process name. In the
b2g era, I believe processes were named based on the "app" that was
running. It would have made sense to have the process initially named
the preallocated process, then to change the process to its app name
when specialized, trying to make it hard/impossible for the process to
rename itself so it couldn't masquerade as another app if it became
compromised.
nsXPIDLStrings are marked as VOIDED upon initialization. Most of these local
nsXPIDLString variables are immediately set via getter_Copies(), which will
either assign a string value (using Adopt()) or do SetIsVoid(). These can be
trivially converted to nsString, which will get the same treatment.
The patch suitably converts the remaining nsXPIDLString local variable as well.
