This will be useful as both an ID for PWindowGlobal, as well as a mechanism for
taking advantage of already synchronized information. As an example, LoadInfo
objects contain the inner window IDs of the window requesting the load, which
can now be used to obtain a reference to the corresponding WindowGlobalParent
in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D9396
This should make BrowsingContext more usable by making it much easier to obtain
for a given frame or browser. BrowsingContext and nsFrameLoader should have
the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D9395
This serves 2 purposes:
1. Provides an object corresponding to an inner window which Chrome JS can hold onto.
2. Provides the object to JS which Chrome JS per-window actors will be attached to.
3. Provides useful information to Chrome JS in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D9394
This allows getting the set of all window globals for a given browsing context.
This is less useful at the moment as the active window global is not exposed as
such. That will be added as a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D9393
This actor can be used for communicating with individual frames, without
depending on walking the tree in the content process.
This is not yet complete. No tests have been written for it, the
WindowGlobalParent objects need to be exposed to chrome JS, and a form of JS
actors should be installed under them.
In addition, BrowsingContextChrome objects should be updated to allow access to
the current WindowGlobalParent in that context.
Differential Revision: https://phabricator.services.mozilla.com/D4623
This has benefits both in terms of performance and memory usage. Aside from
the obvious savings of not loading additional JS scripts in every process,
this also allows us to move more of our expensive data collection work to a
background thread, where it doesn't risk janking both parent and content
processes.
MozReview-Commit-ID: 2A593R7bIKB
Differential Revision: https://phabricator.services.mozilla.com/D13872
--HG--
extra : rebase_source : ec634ee3a3b975809f542aa8077ad32236781452
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
Datastores are preloaded only for content principals. The preloading is triggered as soon as possible to lower the chance of blocking the main thread in content process. If there is no physical database on disk for given origin, datastore is not created. Preloaded datastores are kept alive for 20 seconds.
The implementation is based on a cache (datastore) living in the parent process and sync IPC calls initiated from content processes.
IPC communication is done using per principal/origin database actors which connect to the datastore.
The synchronous blocking of the main thread is done by creating a nested event target and spinning the event loop.
This patch adds some telemetry histograms:
* CONTENT_PROCESS_LAUNCH_IS_SYNC - boolean, true if the content process
was launched synchronously (blocking the main thread)
* CONTENT_PROCESS_SYNC_LAUNCH_MS - the time consumed by sync launch;
the main thread will be busy or blocked for this entire time
* CONTENT_PROCESS_LAUNCH_TOTAL_MS - the total time elapsed from the
start of async content process launch until the launch promise is
resolved and the ContentParent can be sent IPDL messages
* CONTENT_PROCESS_LAUNCH_MAINTHREAD_MS - the time consumed on the parent
process main thread during async content process launch; typically this
is due to ContentParent::Init.
* CHILD_PROCESS_LAUNCH_MS - for any kind of Gecko child process
(including plugins, GPU, etc.), the time taken in the common process
launch code (which is run off-main-thread)
The probes restricted to async content process launch don't have "async"
in the name because that will eventually become the only kind of content
process launch.
Depends on D8943
Differential Revision: https://phabricator.services.mozilla.com/D8944
--HG--
extra : moz-landing-system : lando
There are several layers to this patch:
1. GeckoChildProcessHost now exposes a promise that's resolved when
the process handle is available (or rejected if launch failed), as a
nonblocking alternative to LaunchAndWaitForProcessHandle.
2. ContentParent builds on this with the private method
LaunchSubprocessAsync and the public method PreallocateProcessAsync;
synchronous launch continues to exist for the regular on-demand launch
path, for the time being.
3. PreallocatedProcessManager now uses async launch, and handles the new
"launch in progress" state appropriately.
Depends on D8942
Differential Revision: https://phabricator.services.mozilla.com/D8943
--HG--
extra : moz-landing-system : lando
The first attempt at async launch tried to hide the asynchrony inside
IPC, by making the process seem to be launched enough to construct new
channels and send it messages, and lazily blocking on the pid/handle.
Unfortunately, in practice we wind up needing the pid/handle immediately,
and this requirement is too deeply embedded in IPC for that to be viable.
(The alternative that will be used instead -- exposing process launch via
an explicitly asynchronous promise interface -- is made simpler by
Project Fission's upcoming rewrite of how the DOM requests new content
processes.)
Depends on D8941
Differential Revision: https://phabricator.services.mozilla.com/D8942
--HG--
extra : moz-landing-system : lando
The CONTENT_PROCESS_LAUNCH_TIME_MS histogram is currently gathering times
from two different spans of the launch process and mixing them together;
it's at best a rough approximation of "launch time".
In addition, with async launch we'll want to gather different metrics
than for sync launch (see comments on bug 1474991).
So I'm removing this histogram and will replace it with separate sync and
async metrics in bug 1474991; I intend to land both bugs' patches at or
near the same time, so we won't have a gap in getting some kind of data.
Depends on D8940
Differential Revision: https://phabricator.services.mozilla.com/D8941
--HG--
extra : moz-landing-system : lando
This fixes/adjusts two things about how content process preallocation is blocked:
1. Processes aren't registered as blockers until after they launch
successfully. The main goal is to not leak a blocker if launch fails,
but we don't need to block *while* launching synchronously, because this
all happens on the main thread.
2. Preallocated processes themselves aren't blockers. The main goal
here is so that async preallocation doesn't need extra complexity to
avoid being blocked by itself when launch completes. This mostly
doesn't affect actual behavior, because we currently support at most
one preallocated process. The difference is the window from when the
process is sent its first PBrowserConstructor until when it's next idle,
where there is now no longer a blocker, but this seems to be relatively
short (~100ms) and we don't even try to launch a new process until at
least 1s + an idle runnable.
This patch does not explicitly RemoveBlocker in ActorDestroy like the
first attempt did, because it's unnecessary: this is handled in the
ipc:content-shutdown observer.
Differential Revision: https://phabricator.services.mozilla.com/D8939
--HG--
extra : moz-landing-system : lando
By replacing nsWebBrowser's implementation of the
nsIBaseWindow.initWindow and nsIBaseWindow.create with a new static
nsWebBrowser::Create method we make it possible to pass arguments
directly when creating an nsWebBrowser, for example the opener
BrowsingContext. As a bonus we can do away with
nsWebBrowser::mInitInfo!
Differential Revision: https://phabricator.services.mozilla.com/D12634
--HG--
extra : moz-landing-system : lando
This patch adds some telemetry histograms:
* CONTENT_PROCESS_LAUNCH_IS_SYNC - boolean, true if the content process
was launched synchronously (blocking the main thread)
* CONTENT_PROCESS_SYNC_LAUNCH_MS - the time consumed by sync launch;
the main thread will be busy or blocked for this entire time
* CONTENT_PROCESS_LAUNCH_TOTAL_MS - the total time elapsed from the
start of async content process launch until the launch promise is
resolved and the ContentParent can be sent IPDL messages
* CONTENT_PROCESS_LAUNCH_MAINTHREAD_MS - the time consumed on the parent
process main thread during async content process launch; typically this
is due to ContentParent::Init.
* CHILD_PROCESS_LAUNCH_MS - for any kind of Gecko child process
(including plugins, GPU, etc.), the time taken in the common process
launch code (which is run off-main-thread)
The probes restricted to async content process launch don't have "async"
in the name because that will eventually become the only kind of content
process launch.
Depends on D8943
Differential Revision: https://phabricator.services.mozilla.com/D8944
--HG--
extra : moz-landing-system : lando
There are several layers to this patch:
1. GeckoChildProcessHost now exposes a promise that's resolved when
the process handle is available (or rejected if launch failed), as a
nonblocking alternative to LaunchAndWaitForProcessHandle.
2. ContentParent builds on this with the private method
LaunchSubprocessAsync and the public method PreallocateProcessAsync;
synchronous launch continues to exist for the regular on-demand launch
path, for the time being.
3. PreallocatedProcessManager now uses async launch, and handles the new
"launch in progress" state appropriately.
Depends on D8942
Differential Revision: https://phabricator.services.mozilla.com/D8943
--HG--
extra : moz-landing-system : lando
The first attempt at async launch tried to hide the asynchrony inside
IPC, by making the process seem to be launched enough to construct new
channels and send it messages, and lazily blocking on the pid/handle.
Unfortunately, in practice we wind up needing the pid/handle immediately,
and this requirement is too deeply embedded in IPC for that to be viable.
(The alternative that will be used instead -- exposing process launch via
an explicitly asynchronous promise interface -- is made simpler by
Project Fission's upcoming rewrite of how the DOM requests new content
processes.)
Depends on D8941
Differential Revision: https://phabricator.services.mozilla.com/D8942
--HG--
extra : moz-landing-system : lando
The CONTENT_PROCESS_LAUNCH_TIME_MS histogram is currently gathering times
from two different spans of the launch process and mixing them together;
it's at best a rough approximation of "launch time".
In addition, with async launch we'll want to gather different metrics
than for sync launch (see comments on bug 1474991).
So I'm removing this histogram and will replace it with separate sync and
async metrics in bug 1474991; I intend to land both bugs' patches at or
near the same time, so we won't have a gap in getting some kind of data.
Depends on D8940
Differential Revision: https://phabricator.services.mozilla.com/D8941
--HG--
extra : moz-landing-system : lando
This fixes/adjusts two things about how content process preallocation is blocked:
1. Processes aren't registered as blockers until after they launch
successfully. The main goal is to not leak a blocker if launch fails,
but we don't need to block *while* launching synchronously, because this
all happens on the main thread.
2. Preallocated processes themselves aren't blockers. The main goal
here is so that async preallocation doesn't need extra complexity to
avoid being blocked by itself when launch completes. This mostly
doesn't affect actual behavior, because we currently support at most
one preallocated process. The difference is the window from when the
process is sent its first PBrowserConstructor until when it's next idle,
where there is now no longer a blocker, but this seems to be relatively
short (~100ms) and we don't even try to launch a new process until at
least 1s + an idle runnable.
This patch does not explicitly RemoveBlocker in ActorDestroy like the
first attempt did, because it's unnecessary: this is handled in the
ipc:content-shutdown observer.
Differential Revision: https://phabricator.services.mozilla.com/D8939
--HG--
extra : moz-landing-system : lando
Add some memory usage information to the Performance counters and make everything asynchronous.
Differential Revision: https://phabricator.services.mozilla.com/D7984
--HG--
extra : moz-landing-system : lando
Previously this actor would call `Send__delete__` in its destructor, meaning
that the lifetime of the actor is a bit hard to follow. This changes the actor
to instead use a separate object for XPCOM, and use refcounting universally.
This should also help with the transition to universally refcounted actors.
Differential Revision: https://phabricator.services.mozilla.com/D12955
This should make BrowsingContext more usable by making it much easier to obtain
for a given frame or browser. BrowsingContext and nsFrameLoader should have
the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D9395
Previously this actor would call `Send__delete__` in its destructor, meaning
that the lifetime of the actor is a bit hard to follow. This changes the actor
to instead use a separate object for XPCOM, and use refcounting universally.
This should also help with the transition to universally refcounted actors.
Differential Revision: https://phabricator.services.mozilla.com/D12955
This will be useful as both an ID for PWindowGlobal, as well as a mechanism for
taking advantage of already synchronized information. As an example, LoadInfo
objects contain the inner window IDs of the window requesting the load, which
can now be used to obtain a reference to the corresponding WindowGlobalParent
in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D9396
This should make BrowsingContext more usable by making it much easier to obtain
for a given frame or browser. BrowsingContext and nsFrameLoader should have
the same lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D9395
This serves 2 purposes:
1. Provides an object corresponding to an inner window which Chrome JS can hold onto.
2. Provides the object to JS which Chrome JS per-window actors will be attached to.
3. Provides useful information to Chrome JS in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D9394
This allows getting the set of all window globals for a given browsing context.
This is less useful at the moment as the active window global is not exposed as
such. That will be added as a follow-up.
Differential Revision: https://phabricator.services.mozilla.com/D9393
This actor can be used for communicating with individual frames, without
depending on walking the tree in the content process.
This is not yet complete. No tests have been written for it, the
WindowGlobalParent objects need to be exposed to chrome JS, and a form of JS
actors should be installed under them.
In addition, BrowsingContextChrome objects should be updated to allow access to
the current WindowGlobalParent in that context.
Differential Revision: https://phabricator.services.mozilla.com/D4623
This patch also takes the timeout for killing a content process back to its
original value and removes a related but long unused field.
Differential Revision: https://phabricator.services.mozilla.com/D11739
--HG--
extra : moz-landing-system : lando
Cache the sandboxing command line parameters used when starting a new content process, avoiding calls to realpath(3) on the main thread in the parent process for each content process that is started.
Differential Revision: https://phabricator.services.mozilla.com/D10529
--HG--
extra : moz-landing-system : lando
When creating an instance of nsISpellChecker, we always use
mozSpellChecker::Create. So we should use mozSpellChecker directly instead of
nsISpellChecker.
Differential Revision: https://phabricator.services.mozilla.com/D10993
--HG--
extra : rebase_source : 0feffa60e6dc788904d212a77acbf416279af083
extra : histedit_source : b89cc8270c2df70ae414479f43ac30e8aa0a3d42
This gets rid of an unnecessary allocation.
Differential Revision: https://phabricator.services.mozilla.com/D11066
--HG--
extra : rebase_source : 138c808d78e666e55242bf142269d77fb065d7a6
extra : histedit_source : de8f5f4566cb886e155bce1a22e36f40af7b26f7
All remaining code paths hardcode true here, we can remove this argument.
It wasn't clear to me how this could ever be null before this series. The
only case I could find is that DoFakeShow might be called with a null
RenderFrameChild, but that code is gone now.
Differential Revision: https://phabricator.services.mozilla.com/D11063
--HG--
extra : rebase_source : 872d78ae1b46b0651bc4e109786f4d0d332859c2
extra : histedit_source : 40719e865f2243f90618deba5261124a260ba974
This commit removes all destruction code for RenderFrameParent to be handled by
TabParent. It's important that we remove the layer mapping in ActorDestroy to
prevent a race condition where the TabChild isn't fully destroyed yet and
sends a LayerTransaction constructor to the compositor and hits an
assertion.
Differential Revision: https://phabricator.services.mozilla.com/D11062
--HG--
extra : rebase_source : 61df2cfa3867617c39805883c06649624fffa518
extra : histedit_source : a810303ec335b4ab064dbd56b4652ea4c66deaad
SetRenderFrame() can be implemented in terms of InitRenderFrame(). I'm not sure if
the call to MaybeShow() is necessary, but to be conservative I've moved it into
the window.open path which might need it. BrowserElementParent shouldn't need it
because nsFrameLoader::SetRemoteFrame will call Show().
Differential Revision: https://phabricator.services.mozilla.com/D11061
--HG--
extra : rebase_source : 7d5defc113d107bf77296f1a0a4f7e7dad910db6
extra : histedit_source : 397121af3a86ed3820f055292a8622d3e0bea2b5
We should just have the parent handle initialization here. This lets us
cut down on the information we have to pipe around and simplifies our
amount of code paths.
Differential Revision: https://phabricator.services.mozilla.com/D11060
--HG--
extra : rebase_source : d6c52cb81c7deceb34ad6813d2a55f779d3a1a7d
extra : histedit_source : 4e5a24206e4b8142f2ee788a18c2e186969acfd7
This commit removes the PRenderFrame protocol, while keeping the same ordering
and semantics of graphics IPC initialization.
To do this, some messages are added to PBrowser to simulate the constructor
and destructor of PRenderFrame. Messages that expected a nullable PRenderFrame
are updated to get a boolean instead.
One tricky area is the destruction of PRenderFrame. I've tried to keep it the
same as much as possible, but it's possible it might be slightly semantically
different than IPDL destruction. Destruction will be touched up in a later
patch, so I'm not too concerned.
Differential Revision: https://phabricator.services.mozilla.com/D11057
--HG--
extra : rebase_source : bb8a7896bb4aefb6e9957d8808b755fa76cc00ed
extra : histedit_source : 6377819a946b5b6bc18b15f748229360e42a6f3a
When creating an instance of nsISpellChecker, we always use
mozSpellChecker::Create. So we should use mozSpellChecker directly instead of
nsISpellChecker.
Differential Revision: https://phabricator.services.mozilla.com/D10993
--HG--
extra : moz-landing-system : lando
This commit removes a bunch of cruft from RenderFrameParent that isn't
used and isn't needed. Some functions that have no reason to be in
RenderFrameParent are moved to TabParent in anticipation of the
PRenderFrame protocol being dropped.
Differential Revision: https://phabricator.services.mozilla.com/D10411
--HG--
extra : rebase_source : 79f830e0ad48e868480108c3bbb01e3faca5e70a
extra : histedit_source : 4ddb361e4e4acae10ab16124b5d6548490f770ee
This commit attempts to lower the pain of modifying FrameMetrics.h.
It looks like most includes really only want ViewID or
ScrollableLayerGuid, so this commit factors them out into a separate
header. In the process FrameMetrics::ViewID is changed to
ScrollableLayerGuid::ViewID, which personally seems like a better
place for it now that we have RepaintRequest. Unfortunately that
requires a lot of places to be updated.
After this commit there are still a couple of major places that
FrameMetrics is included.
* nsDisplayList.h
* nsIScrollableFrame.h
* Layers.h
Those are going to be more tricky or impossible to fix so they're
not in this commit.
Differential Revision: https://phabricator.services.mozilla.com/D10722
--HG--
rename : gfx/layers/FrameMetrics.h => gfx/layers/ScrollableLayerGuid.h
rename : gfx/layers/FrameMetrics.h => gfx/layers/ZoomConstraints.h
extra : rebase_source : 29ac79f91460a181bf7437af5c371207e22858e2
extra : source : c2e70e531075493fc6e374dcec862827f0bc6e77
This field was originally added for the b2g-only DeviceStorage API,
and isn't used for anything else right now.
This reverts the remaining parts of bug 1043136 and bug 1043136
as well as some support code for mobile.
Differential Revision: https://phabricator.services.mozilla.com/D10014
--HG--
extra : moz-landing-system : lando
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
Content process of Android uses sync IPC when initializing LookAndFeel. But
current e10s has LookAndFeel cache for start up of content process.
So we should use it, then remove sync IPC for start up performance
Differential Revision: https://phabricator.services.mozilla.com/D9750
--HG--
extra : moz-landing-system : lando
When early sandbox setartup is enabled, revert to sending SetProcessSandbox() to the child process as before. In the child process RecvSetProcessSandbox() handler, call CGSShutdownServerConnections() and then return early if the sandbox is already enabled.
Differential Revision: https://phabricator.services.mozilla.com/D9827
--HG--
extra : moz-landing-system : lando
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
Differential Revision: https://phabricator.services.mozilla.com/D6944
--HG--
rename : docshell/base/nsDocShellLoadInfo.cpp => docshell/base/nsDocShellLoadState.cpp
rename : docshell/base/nsDocShellLoadInfo.h => docshell/base/nsDocShellLoadState.h
extra : moz-landing-system : lando
FrameMetrics is currently used in about three ways.
1. Main thread to APZ transactions
2. Storing information in AsyncPanZoomController
3. APZ to main thread repaint requests
There's overlap in the use of fields in all these use cases, but it's not perfect. In a
following commit, I'd like to change the information used for (1) to support relative
scroll offset updates. This information isn't needed for (2) or (3), so it would be
good to refactor FrameMetrics out into these use cases.
This commit refactors out (3) as it is fairly easy to do. I'd like to refactor (2) out
as well, but that is trickier. I'd like to leave that for a future followup.
Differential Revision: https://phabricator.services.mozilla.com/D7127
--HG--
extra : rebase_source : f0be2be24fce7d0f0ed25f6f3bfab5f7f2864f23
extra : source : fc9898a9ab28cee292e201ddaf757ee267179433
extra : histedit_source : 35415d3dc2c0ae0f269994c385cceff75f150020
Only allow access to "com.apple.windowserver.active" when the pref
"security.sandbox.content.mac.disconnect-windowserver" is set to true.
Depends on D6721
Differential Revision: https://phabricator.services.mozilla.com/D7357
--HG--
extra : moz-landing-system : lando
When early initialization of the sandbox is enabled, assert that the sandbox has already been enabled in ContentProcess::Init().
Depends on D6720
Differential Revision: https://phabricator.services.mozilla.com/D6721
--HG--
extra : moz-landing-system : lando
Pass sandbox parameters to content processes on the command line allowing for early sandbox startup.
Pref'd off behind "security.sandbox.content.mac.earlyinit" until it's ready to be enabled by default.
Once early startup is enabled by default and considered stable, the original sandbox startup code can be removed.
Depends on D6719
Differential Revision: https://phabricator.services.mozilla.com/D6720
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR. Change APP_PATH to be the path to the parent process .app directory and make GetAppPath return this path when called from the parent or a child process.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
Differential Revision: https://phabricator.services.mozilla.com/D6944
--HG--
rename : docshell/base/nsDocShellLoadInfo.cpp => docshell/base/nsDocShellLoadState.cpp
rename : docshell/base/nsDocShellLoadInfo.h => docshell/base/nsDocShellLoadState.h
extra : moz-landing-system : lando
nsRefreshDriver::ObserverArray is a nsTObserverArray which is
infallible, so no need to check the return value from AppendElement
(which a later patch in this series will remove).
Only allow access to "com.apple.windowserver.active" when the pref
"security.sandbox.content.mac.disconnect-windowserver" is set to true.
Depends on D6721
Differential Revision: https://phabricator.services.mozilla.com/D7357
--HG--
extra : moz-landing-system : lando
When early initialization of the sandbox is enabled, assert that the sandbox has already been enabled in ContentProcess::Init().
Depends on D6720
Differential Revision: https://phabricator.services.mozilla.com/D6721
--HG--
extra : moz-landing-system : lando
Pass sandbox parameters to content processes on the command
line allowing for early sandbox startup. Limited to Nightly
until confirmed to be stable and ready to ride the trains.
Enable early sandbox startup by default on Nightly and use
pref "security.sandbox.content.mac.earlyinit" to disable
early startup for debugging purposes.
Once early startup is stable, the original sandbox startup
code can be removed.
Depends on D6719
Differential Revision: https://phabricator.services.mozilla.com/D6720
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
This commit adds a CrossProcessPaint class which can be used to paint a
cross process document tree. This API is async, as we cannot block on child
processes, and initially geared towards servicing a JS API and not internal
consumers. The API can only be used in the chrome process for security
reasons.
The class is implemented as a recursive resolver, requesting a root paint,
gathering dependent frames to be painted, then requesting paints from those
tabs. Once all paints have been completed, the dependency tree is rasterized
in a bottom up fashion.
Future improvements can be made here. Currently, the rasterization is
performed on the main thread which could cause jank. We also transmit
recordings directly over IPDl, and no effort is made to minimize the
recordings from child layer trees.
Differential Revision: https://phabricator.services.mozilla.com/D6790
--HG--
extra : rebase_source : b213de269b33486552ddc0be17207f9fb3f78c9c
This commit adds a method to get the ContentParentId for a specified TabId. This will be used
to get the TabParent from a specified TabId.
Differential Revision: https://phabricator.services.mozilla.com/D6783
--HG--
extra : rebase_source : 8e8874cc41f2a816855ba69331fb83ae48de5df6
Only allow access to "com.apple.windowserver.active" when the pref
"security.sandbox.content.mac.disconnect-windowserver" is set to true.
Depends on D6721
Differential Revision: https://phabricator.services.mozilla.com/D7357
--HG--
extra : moz-landing-system : lando
When early initialization of the sandbox is enabled, assert that the sandbox has already been enabled in ContentProcess::Init().
Depends on D6720
Differential Revision: https://phabricator.services.mozilla.com/D6721
--HG--
extra : moz-landing-system : lando
Pass sandbox parameters to content processes on the command
line allowing for early sandbox startup. Limited to Nightly
until confirmed to be stable and ready to ride the trains.
Enable early sandbox startup by default on Nightly and use
pref "security.sandbox.content.mac.earlyinit" to disable
early startup for debugging purposes.
Once early startup is stable, the original sandbox startup
code can be removed.
Depends on D6719
Differential Revision: https://phabricator.services.mozilla.com/D6720
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
Our current prioritization mechanism doesn't account for tab
warming, or for the fact that the current tab should be
deprioritized. This corrects that.
Differential Revision: https://phabricator.services.mozilla.com/D7205
--HG--
extra : moz-landing-system : lando
All implementations of these methods fail immediately. This patch removes them,
and replaces their call sites with failures. Code coverage indicates these
locations aren't hit by any of our tests.
--HG--
extra : rebase_source : 3c44ac20213af97865ad0316e65bfe49b9e5818c
This also removes the (afaict, unused) stub implementation from TabParent. The netwerk header
inclusions were necessary because those files included TabParent.h and through it,
nsISecureBrowserUI, but now TabParent.h no longer does that.
Differential Revision: https://phabricator.services.mozilla.com/D6829
--HG--
extra : moz-landing-system : lando
This reverts the changes in bug 1360308, bug 1390143 and bug 1469603. Minidump
generation will now only happen on the main process' main thread which might
lead to hangs but is known to be fairly robust. Asynchronous generation proved
too brittle and enormously increased the complexity of this already
hard-to-read code.
Differential Revision: https://phabricator.services.mozilla.com/D5147
--HG--
extra : moz-landing-system : lando
Create ChromeBrowsingContext and move parent process specific parts
from BrowsingContext there. After that make sure that all
BrowsingContexts created in the parent process is actually
ChromeBrowsingContexts and all BrowsingContexts in the child processes
are BrowsingContexts.
Differential Revision: https://phabricator.services.mozilla.com/D5419
--HG--
extra : moz-landing-system : lando
The framework to simulate the setting change works as following;
- nsIDOMWindowUtils.setPrefersReducedMotion() calls an IPC function which ends
up calling nsChildView::SetPrefersReducedMotion() in the parent process
- nsChildView::SetPrefersReducedMotion() sets the given value into
nsLookAndFeel::mPrefersReducedMotionCached just like we set the value queried
via NSWorkspace.accessibilityDisplayShouldReduceMotion in the parent process
and send a notification which is the same notification MacOSX sends when the
system setting changed
- Normally the cached value is cleared before quering new values since the
cache value is stale, but in this case the value is up-to-date one, so
nsChildView::SetPrefersReducedMotion() tells that we don't need to clear the
cache, and nsIDOMWindowUtils.resetPrefersReducedMotion() resets that state
of 'we don't need to clear the cache'
There are two test cases with the framework in this commit, one is just setting
the value and checking the value queried by window.matchMedia. The other one is
receiving 'change' event and checking the value of the event target.
Note that to make this test works the patch for bug 1478212 is necessary since
the test runs in an iframe.
Depends on D5003
Differential Revision: https://phabricator.services.mozilla.com/D5004
--HG--
extra : moz-landing-system : lando
This makes sure to release blockers (so that content process
preallocation can resume) in error cases, and stops making preallocated
processes themselves blockers, because it's unnecessary (we don't
currently support multiple preallocated processes) and not doing it
means not having to handle those error cases as well.
(Also, in the future we might want to allow the possibility of multiple
concurrent launches if the hardware can support it with acceptable
performance.)
Differential Revision: https://phabricator.services.mozilla.com/D5725
--HG--
extra : moz-landing-system : lando
Turned out to be fairly trivial. Not much to explain here - as far
as I can tell this looks clean on try now (no web extension failures
like there were before).
Differential Revision: https://phabricator.services.mozilla.com/D5280
--HG--
extra : moz-landing-system : lando
This patch removes the 'ScreenOrientationInternal' type from
dom/base/ScreenOrientation.h and moves it into the
HalScreenConfiguration.h header, renaming it simply to 'ScreenOrientation'
in the process. This has several knock-off effects:
- It allows files that needed ScreenOrientationInternal to include a much
smaller header than before
- It greatly reduces the number of headers pulled in when including Hal.h
- It clarifies the role of the type. The 'Internal' part in the name had
nothing to do with it being part of the implementation. The type was public
and called that way only to avoid clashing with the 'ScreenOrientation'
class. Since we moved it into a different namespace it can be renamed
safely.
- It allows a file that was manually re-declaring 'ScreenConfigurationInternal'
type to use the original one
- Finally this fixes a few files which were missing headers they actually
required but that would still build because unified compilation put them into
units that already had those headers thanks to ScreenConfiguration.h
Differential Revision: https://phabricator.services.mozilla.com/D4458
--HG--
extra : moz-landing-system : lando
There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
Add StartOpenBSDSandbox method calling pledge() syscall,
and use it where we're sandboxing processes.
The pledge subsets are coming from two new prefs:
- security.sandbox.pledge.content for the content process
- security.sandbox.pledge.main for the main process
--HG--
extra : rebase_source : 60da70e2d335755fda6126a6b7de7aad41eebb7e
This moves the code that detects very low memory scenarios and grabs memory
reports from the main thread event-loop to the available memory tracker.
Besides removing the overhead of the check from the event-loop code this
increases the likeliness of the reports being gathered by sampling at a
higher frequency but only when we already detected a low-memory scenario. Last
but not least this add checks for low commit-space detection alongside low
virtual-memory detection.
Differential Revision: https://phabricator.services.mozilla.com/D3669
--HG--
extra : moz-landing-system : lando
Having to add pagehide/pageshow listeners to the chrome event target is a
serious inconvience for the use cases of this bug. Dispatching to system group
listeners has approximately the same effect as the old code, but is much
easier for window-bound code to handle.
--HG--
extra : rebase_source : d67c14e9ba91772d8a9dd82481120b34bdb551e0
The test case in this patch fails without the proper fix in the first patch
in this patch series.
In this patch two new nsIDOMWindowUtils APIs are introduced to change the
system font settins in tests. Currently the APIs work only on GTK+ platform.
Also to work the test case properly we need to open a new XUL window because we
don't propagate font changes into descendant documents yet (bug 1478212).
MozReview-Commit-ID: 4OLxEkEuF8d
--HG--
extra : rebase_source : 683e64f07c4d8820e5499d8c15b90975618559b8
This is mostly self-explanatory. However, the patch also contains some minor
changes to frame scripts which expect to be able to call message manager
methods with a null target object, which stops working when they stop being
global objects.
MozReview-Commit-ID: HDT2RvK3F3L
--HG--
extra : rebase_source : bb3ce8861a261ff1bc28a28b3ff88ba0deaef552
After these patches, these objects will no longer be globals, which would make
their current names misleading. Parts 1a-1c give more appropriate names to the
bindings which will cease to be globals.
MozReview-Commit-ID: L8GolQaHnO5
--HG--
rename : dom/base/ProcessGlobal.cpp => dom/base/ContentProcessMessageManager.cpp
rename : dom/base/ProcessGlobal.h => dom/base/ContentProcessMessageManager.h
extra : rebase_source : c5db43ff4f56bc27c869a8051c8d2c000b3fe287
This adds the basic framework for defining IPC actors which are lazily
instantiated for the appropriate frame loaders based on DOM events, message
manager messages, and observers. Actual actors are defined in follow-up
commits.
MozReview-Commit-ID: Jb6CWWW7v3v
--HG--
extra : rebase_source : 6c465c492ef423616346d70047c4fd4b074af303
Browsers can switch at runtime from remote to non-remote and vice versa,
which on the C++ side is detected from a XBL binding change which causes
nsIRemoteBrowser to either be implemented or not. Custom Elements can't
change at runtime in the same way, so unifying on a single [implements]
will allow browser (both remote and non-remote) to be migrated to a single
Custom Element.
To keep current functionality, this updates Qi calls into nsIRemoteBrowser
to instead Qi into nsIBrowser and check isRemoteBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D3346
--HG--
extra : moz-landing-system : lando
They'll be reopened, so there's no security benefit, but this causes Activity
Monitor to not report the processes as 'not responding'.
Differential Revision: https://phabricator.services.mozilla.com/D2855
--HG--
extra : moz-landing-system : lando
They'll be reopened, so there's no security benefit, but this causes Activity
Monitor to not report the processes as 'not responding'.
Differential Revision: https://phabricator.services.mozilla.com/D2855
--HG--
extra : moz-landing-system : lando
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
Summary:
Only implemented by nsWebBrowser, only 2 methods used in TabChild.
Move methods to nsWebBrowser implementation and remove unused methods,
change names to something more obvious, and remove interface.
MozReview-Commit-ID: 4WwBrVWQEVy
Test Plan: Try run
Reviewers: nika
Tags: #secure-revision
Bug #: 1480645
Differential Revision: https://phabricator.services.mozilla.com/D2752
Summary:
We only use one branch of the property set method in
nsIWebBrowserSetup, in one place. Expose this setting in the C++ API
and remove the XPCOM interface.
This patch also exposes the nsWebBrowser.h header to the codebase,
meaning we can possibly start removing some uses of nsIWebBrowser
elsewhere.
MozReview-Commit-ID: G3gnRWJUx6M
Test Plan: Try run
Reviewers: nika
Tags: #secure-revision
Bug #: 1480643
Differential Revision: https://phabricator.services.mozilla.com/D2736
We originally thought that this would enable us to disconnect from the
windowserver local service (which is a significant sandbox escape risk),
however investigations revealed that that requires changes to WebGL and thus
will be handled separately.
This also corrects an incorrect usage of the (undocumented) APIs for closing
windowserver connections. If CGSSetDenyWindowServerConnections is called while
there are open connections it is a no-op, so it must be called after
disconnecting any open connections.
Differential Revision: https://phabricator.services.mozilla.com/D2478
--HG--
extra : moz-landing-system : lando
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : b4f0d4bf83c64851028c271d3fab3ebcb6fbcd3e
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : f0e8d229581ac5c0daa0e0454cb258746108e28d
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
I generally tried to preserve the behavior of consumers where they treated an
exception from getInterface(Ci.nsIContentFrameMessageManager) as a signal to use
some sort of fallback.
I did change the behavior of consumers that walked up to the root same-type
docshell before getting the message manager to just get it directly from the
docshell they have. Please review those parts carefully, and let me know if you
want me to ask some subject area experts to review those.
Fairly straightforward. This should allow us to enable our
forcepaint telemetry again without an added cost, since it's
just piggybacking on the existing content process BHR.
MozReview-Commit-ID: 83l9xnPfc9u
--HG--
extra : rebase_source : d53f1e9adfff1d9bf3610be634f9ece08a2ec154
This new id is added in the PerformanceInfo data and helps consumers distinguish
counters.
MozReview-Commit-ID: 7kEmqJcVggM
--HG--
extra : rebase_source : 40cca4c937f846db93ec1315036ad1bac04bc762
To not leave dangling BrowsingContexts due to crashing child processes
we need to detach all BrowsingContexts owned by a specific process
when that process goes away.
--HG--
extra : histedit_source : a737dd272224ae2595e8851813f3f9a66a2e01f2
Have BrowsingContext keep its own cache to enable caching of
BrowsingContexts, especially in the parent process.
This isn't really optimal, since it effectively duplicates the
cache in the child process. BFcache keeps a list of strong pointers to
the list of cached nsDocShells, where each nsDocShell in turn keeps a
reciprocated strong pointer to its BrowsingContext, which in turn is
held in the BrowsingContexts list of cached contexts. Ideally these
caches should be merged.
--HG--
extra : histedit_source : 094370f6d54d83728e8433ec5c47003086146476
Add BrowsingContext to allow the tree structure of docshells to exist
in several processes simultaneously. This is a first step towards
allowing a tree structure preserving separation of docshells across
processes.
--HG--
extra : histedit_source : d3c7f6ab4b9ae76f170c126d669ebd570e52f348
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : 9c400bed3c9d29a186fc987c9bd0ffceb37bfd94
- Access nsISSLStatus directly as a member of nsITransportSecurityInfo
and nsISecureBrowserUI. This is part of a larger effort to consolidate
nsISSLStatus and nsITransportSecurityInfo.
- The TabParent implementation of GetSecInfo will always return null.
- Removed unnecessary QueryInterface calls
- Style adherence updates
MozReview-Commit-ID: Dzy6t2zYljL
--HG--
extra : rebase_source : fbfbcf7608efbfb35c9be4018ff0f4e70b2768d2
Brindusan Cristian
Neil Deakin
Sylvestre Ledru
Nika Layzell
Kris Maglione
Michael Froman
Noemi Erli
Nils Ohlmeier [:drno]
Tooru Fujisawa
Benjamin Bouvier
Jan Varga
Coroiu Cristina
Jan-Erik Rediger
Jed Davis
Mats Palmgren
Andreas Farre
Andreea Pavel
Ehsan Akhgari
Mark Banner
Mike Conley
Razvan Maries
Tarek Ziadé
Lina Cambridge
Csoregi Natalia
arthur.iakab
Gabriele Svelto
Bogdan Tara
Haik Aftandilian
Dorel Luca
Andrea Marchesini
Ryan Hunt
Makoto Kato
Daniel Varga
Eden Chuang
Cosmin Sabou
Marco Castelluccio
Julian Descottes
Jonathan Kingston
Kyle Machulis
Narcis Beleuzu
Brian Hackett
Diego Pino Garcia
Gurzau Raul
Boris Zbarsky
Tiberius Oros
Andrew McCreight
Doug Thayer
Edgar Chen
sotaro
Nicholas Nethercote
Gijs Kruitbosch
Hiroyuki Ikezoe
Jonathan Kew
Daniel Holbert
Landry Breuil
Jeff Walden
Margareta Eliza Balazs
Brian Grinstead
Ting-Yu Lin
Alex Gaynor
Adrian Wielgosik
Jan de Mooij
Kartikaya Gupta
Zibi Braniecki
Blake Kaplan
Dipen Patel