Passes the profile dir to the content process as a -profile CLI
option so that the correct profile dir can be used in the OS X content
sandbox rules. Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected
from the content process (apart from a few profile subdirectories) even
when they don't reside in ~/Library.
xpcshell tests invoke the content process without providing a
profile directory. In that case, we don't need to add filesystem
profile dir. read/write exclusion rules to the sandbox.
This patch adds two new macros to the content sandbox rule set:
|profileDir| holds the path to the profile or the emptry string;
|hasProfileDir| is a boolean (1 or 0) that indicates whether or
not the profile directory rules should be added. If |hasProfileDir|
is 0, profile directory exclusion rules don't need to be added
and |profileDir| is not used.
MozReview-Commit-ID: rrTcQwTNdT
--HG--
extra : rebase_source : 3d5b612c8eb3a1d0da028eba277cd9d6f0c9ac00
We currently allow nested event loop to delay ContentChild::RecvShutdown
which in turn might cause content process shutdown hang. This patch
attempts to annotate the crash report that a shutdown hang was after we
have received RecvShutdown but never reach SendFinishShutdown or the
hang happened before or after RecvShutdown.
MozReview-Commit-ID: 8pGqwzLlYpK
--HG--
extra : rebase_source : 78fdec0c29ded1abbd6651c67fe5c97f63555635
We currently make the initial browser in a window remote by default. If early
on in the session, that one remote browser goes away (and the content process
was still booting), there's about 5 seconds before the shutdown kill timer
will take that content process out for not quitting fast enough.
There are some cases during startup where the content process is waiting
on information from the parent, so it cannot respond to the request to
quit in time. The parents shutdown kill timer goes off, and the shutdown
kill occurs.
In this bug, what's happening is that the initial browser flips remoteness
from remote to non-remote when it goes to about:sessionrestore. This starts
the shutdown kill timer. The content process runs out of time, and the
shutdown kill timer fires, killing the content process. The TabParent::ActorDestroy
method (which still exists, even though the browser is no longer remote),
interprets this as an abnormal shutdown, and bubbles the oop-browser-crashed
event to the associated <xul:browser>, which causes the page to browser to
about:tabcrashed, when it had already loaded about:sessionrestore.
This patch makes it so that the TabParent::ActorDestroy method first checks
to ensure that the associated remote frameloader is still the one that the
frameloader owner cares about. If not (because, say, the remoteness has
flipped and a new non-remote frameloader has been created), then the
event is not fired, since the user has moved on.
MozReview-Commit-ID: G4jmR6lMMFl
--HG--
extra : rebase_source : 7e752d9854d6c17b2b346cc986c0fbad00292848
We currently make the initial browser in a window remote by default. If early
on in the session, that one remote browser goes away (and the content process
was still booting), there's about 5 seconds before the shutdown kill timer
will take that content process out for not quitting fast enough.
There are some cases during startup where the content process is waiting
on information from the parent, so it cannot respond to the request to
quit in time. The parents shutdown kill timer goes off, and the shutdown
kill occurs.
In this bug, what's happening is that the initial browser flips remoteness
from remote to non-remote when it goes to about:sessionrestore. This starts
the shutdown kill timer. The content process runs out of time, and the
shutdown kill timer fires, killing the content process. The TabParent::ActorDestroy
method (which still exists, even though the browser is no longer remote),
interprets this as an abnormal shutdown, and bubbles the oop-browser-crashed
event to the associated <xul:browser>, which causes the page to browser to
about:tabcrashed, when it had already loaded about:sessionrestore.
This patch makes it so that the TabParent::ActorDestroy method first checks
to ensure that the associated remote frameloader is still the one that the
frameloader owner cares about. If not (because, say, the remoteness has
flipped and a new non-remote frameloader has been created), then the
event is not fired, since the user has moved on.
MozReview-Commit-ID: G4jmR6lMMFl
--HG--
extra : rebase_source : 7e752d9854d6c17b2b346cc986c0fbad00292848
Batch the accumulations to only transmit every so often, so we don't incur
too much in the way of IPC overhead penalties.
What this doesn't do:
* remove or restructure child telemetry code to adapt to the new way
* send the telemetry anywhere
* allow for the child process to clear child histograms
* support anything but histograms (but this is expected and okay)
MozReview-Commit-ID: JnUkcmN3Ya7
This patch prevents the Windows widget code from dispatching the contextmenu
event if APZ is handling touch input. Instead, the APZ code processes the
raw touch input, and will fire a contextmenu event when the user lifts their
finger after a long-press action, in keeping with the Windows platform
convention. Doing it this way also allows us to respect web conventions where
the web content can prevent the contextmenu event from firing by calling
preventDefault on the touchstart event; this was not possible when dispatching
the contextmenu event directly from the widget code.
This also makes long-pressing on browser chrome components work properly, as
it just shifts the point in time that the contextmenu event is fired without
changing any of the code that triggers the XUL popup. However, some changes
were needed to have the widget code ignore the synthetic mouse events that
the Windows platform sends us, because those would otherwise immediately
dismiss the contextmenu popup after it appeared.
MozReview-Commit-ID: 9HFZLC6xUAi
--HG--
extra : rebase_source : aea932d9f95454c585bcdf962d151c946b5c6ec2
Batch the accumulations to only transmit every so often, so we don't incur
too much in the way of IPC overhead penalties.
What this doesn't do:
* remove or restructure child telemetry code to adapt to the new way
* send the telemetry anywhere
* allow for the child process to clear child histograms
* support anything but histograms (but this is expected and okay)
MozReview-Commit-ID: JnUkcmN3Ya7
Batch the accumulations to only transmit every so often, so we don't incur
too much in the way of IPC overhead penalties.
What this doesn't do:
* remove or restructure child telemetry code to adapt to the new way
* send the telemetry anywhere
* allow for the child process to clear child histograms
* support anything but histograms (but this is expected and okay)
MozReview-Commit-ID: JnUkcmN3Ya7
Passes the profile dir to the content process as a -profile CLI option so
that the correct profile dir can be used in the OS X content sandbox rules.
Only enabled on OS X for now.
On Nightly, profile directories will now be read/write protected from the
content process (apart from a few profile subdirectories) even when they
don't reside in ~/Library.
MozReview-Commit-ID: rrTcQwTNdT
--HG--
extra : rebase_source : d91d8939cabb0eed36b640766756548a790a301c
This change avoids lots of false positives for Coverity's CHECKED_RETURN
warning, caused by NS_WARN_IF's current use in both statement-style and
expression-style.
In the case where the code within the NS_WARN_IF has side-effects, I made the
following change.
> NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
> -->
> Unused << NS_WARN_IF(NS_FAILED(FunctionWithSideEffects()));
In the case where the code within the NS_WARN_IF lacks side-effects, I made the
following change.
> NS_WARN_IF(!condWithoutSideEffects);
> -->
> NS_WARNING_ASSERTION(condWithoutSideEffects, "msg");
This has two improvements.
- The condition is not evaluated in non-debug builds.
- The sense of the condition is inverted to the familiar "this condition should
be true" sense used in assertions.
A common variation on the side-effect-free case is the following.
> nsresult rv = Fn();
> NS_WARN_IF_(NS_FAILED(rv));
> -->
> DebugOnly<nsresult rv> = Fn();
> NS_WARNING_ASSERTION(NS_SUCCEEDED(rv), "Fn failed");
--HG--
extra : rebase_source : 58788245021096efa8372a9dc1d597a611d45611
