Remove old content sandbox code paths that allowed the sandbox to be started
later during content process startup when the SetProcessSandbox() message was
received from the parent process. This older way of starting the sandbox was
still in the tree to support WebReplay which is now being removed. With this
fix, content processes always use the "earlyinit" sandbox startup like the
RDD and GMP processes.
Differential Revision: https://phabricator.services.mozilla.com/D64968
--HG--
extra : moz-landing-system : lando
This patch includes the implementation of propagating declared playback state from the media session in the content process to the media session controller in the chrome process.
Differential Revision: https://phabricator.services.mozilla.com/D66341
--HG--
extra : moz-landing-system : lando
Note that this also suppresses notifications from the initial about:blank in the new process, and updates the tabbrowser to not expect those.
Differential Revision: https://phabricator.services.mozilla.com/D65923
--HG--
extra : moz-landing-system : lando
Before this patch, PSM would register content type handlers to handle certain
certificate types. This was an easy way to install a client certificate after
generating a key with <keygen>, but keygen has been removed. This was also an
easy way to install root certificates, but that's actually a considerable
security risk. We kept this functionality for so long because it was the only
way to add a 3rd-party root certificate to Fennec's certificate store. Now that
Fennec is EOL, we can remove it. (Fenix will need a way to trust 3rd party root
certificates, but the path forward there is to implement the enterprise roots
feature for Android.)
Differential Revision: https://phabricator.services.mozilla.com/D66118
--HG--
extra : moz-landing-system : lando
For Win32k lockdown, we need to remove the content processes' ability to
call GetICMProfileW(). Since it needs this to retrieve the output color
profile, a new synchronous call is added that allows it to request the
parent process to read this file on its behalf.
The contents of the file are now being cached as well, as this should help
ease some of the increased parent process I/O caused by the children not
being able to do this in their process anymore.
Differential Revision: https://phabricator.services.mozilla.com/D66126
--HG--
extra : moz-landing-system : lando
The patch adds similar to mousemove compression on IPC layer.
https://searchfox.org/mozilla-central/rev/49ed791eec93335abfe6c2880f84c324e73e47e6/dom/ipc/PBrowser.ipdl#764-774
Touch events can't be compressed all the time, because each touch event
may contain changes to several touches.
To disable compression in some cases, another IPC message is sent.
The messages have exactly the same arguments, but by changing the message type,
compression is disabled for that message on IPC layer.
The patch tries to take rather conservative approach by disabling compression
in many cases. Compression is enabled only if the same touches are being changed,
or old touches and some new touch are changed (so the changed touches are a superset of the old touches).
The patch does not do anything with PointerEvent.getCoalescedEvents(). That implementation
would be quite a bit different and riskier for the next coming Fenix release.
Differential Revision: https://phabricator.services.mozilla.com/D63261
--HG--
extra : moz-landing-system : lando
When searching for the controller for a command in nsWindowRoot::GetControllerForCommand, look for a focused browsing context instead and get the controller through the Controllers actor associated with that browsing context. When a command update occurs in a window in the child process, send the list of commands to the parent process along with the browsing context for that window. The parent will pass this information to the controllers actor. As long as we can get the right currently focused browsing context descendant, we can get the correct command state and invoke commands through the right actor.
Differential Revision: https://phabricator.services.mozilla.com/D66222
--HG--
rename : toolkit/modules/RemoteController.jsm => toolkit/actors/ControllersParent.jsm
extra : moz-landing-system : lando
AudioSession, which handles things like making sure that the volume slider in the system tray has the right name and icon and is aligned for all processes, is not needed in content processes any longer since bug 1432303 remoted audio use away from content.
Differential Revision: https://phabricator.services.mozilla.com/D64445
--HG--
extra : moz-landing-system : lando
Crash annotations in content processes are currently sent over IPC via
shared memory buffers. To pave the way for the Rust rewrite of the exception
handler we are removing this code and gathering all the crash annotations
within the content processes themselves. This patch causes annotations to be
stored in the global table of each content process. They are then streamed
out to the parent process by the exception handler together with the
exception-time annotations.
This has a number of benefits:
* we have one less channel to exchange data between content processes and
the parent process
* we save memory because we don't need to allocate the shared memory buffers
* annotations are faster because we don't stream them all out every time one
changes
* we won't truncate annotations anymore if we run out of space in the shared
segment.
* we don't need delayed annotations anymore, so we can get rid of the
associated machinery
As I refactored the code I tried to adjust all the obsolete comments,
consolidate shared code and remove the redundant steps that were sometimes
present. In many places we had two entire crash annotation tables we merged to
change just a couple; that comes from the fact that historically we loaded
them from disk. Now it doesn't matter anymore and we can just go ahead and
change the ones we care about.
Differential Revision: https://phabricator.services.mozilla.com/D62586
--HG--
extra : moz-landing-system : lando
WalkHistoryEntries function gets called by nsSHistory::CloneAndReplaceChild
and nsSHistory::SetChildHistoryEntry recursively, so those have to be moved
into the parent process. This eliminates many sync IPC calls.
To facilitate transition to a new session history design,
we are mirroring mOSHE and mLSHE SH entries from docshell to browsing context.
Whenever we update those entries in docshell, we will also update those in BC,
and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D56201
--HG--
extra : moz-landing-system : lando
Shutting down the process is going to free more memory than anything else we
could do, so don't delay it.
Differential Revision: https://phabricator.services.mozilla.com/D66082
--HG--
extra : moz-landing-system : lando
layout/reftests/bugs/370422-1.html changes the size of a fission iframe.
Bug 1615504 made sure the visible rect got to the child process. But there is still a failure mode where (I assume) all invalidations/painting of changing the document size in the iframe content process happens before the effects visible rect ipc msg arrives at the content process.
In this case we still need to invalidate even though we use the correct visible rect on the builder we need a dirty rect that includes the unveiled area.
Depends on D65888
Differential Revision: https://phabricator.services.mozilla.com/D65889
--HG--
extra : moz-landing-system : lando
Also logs JSWindowActor{Child,Parent}::Init and JSWindowActor::{Start,After}Destroy.
Originally authored by :freddyb.
Differential Revision: https://phabricator.services.mozilla.com/D45346
--HG--
extra : moz-landing-system : lando