Expose requestIdleCallback on Window and implement running callbacks
in idle periods by posting rICs to the main threads idle queue.
MozReview-Commit-ID: KSYQsyaZ6is
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
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
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");
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
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.
This patch removes checking of all the callback calls in memory reporter
CollectReport() functions, because it's not useful.
The patch also does some associated clean-up.
- Replaces some uses of nsIMemoryReporterCallback with the preferred
nsIHandleReportCallback typedef.
- Replaces aCallback/aCb/aClosure with aHandleRepor/aData for CollectReports()
parameter names, for consistency.
- Adds MOZ_MUST_USE/[must_use] in a few places in nsIMemoryReporter.idl.
- Uses the MOZ_COLLECT_REPORT macro in all suitable places.
Overall the patch reduces code size by ~300 lines and reduces the size of
libxul by about 37 KiB on my Linux64 builds.
Automatically destroy TabParent if *aResult is not NS_OK
or *aWindowIsNew is false.
We should never call PBrowserChild::Send__delete__ directly in content
process because the parent side needs to do some cleanup first. In this
case if OpenWindowWithTabParent failed but the TabParent has been
associated with a nsFrameLoader we could crash on trying to destroy a
already destroyed TabParent.
MozReview-Commit-ID: E2KFn6yA1Fm