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
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
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
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
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
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
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
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
We were previously failing to send blobs to new content processes, which was a
problem for those processes. But we were also attempting to extract blobs for
new entries that we were serializing after we'd extracted their structured
clone data, and their blob array had been thrown away (which was a problem for
all processes).
This patch fixes both problems.
MozReview-Commit-ID: 3qbAmUTA85g
--HG--
extra : rebase_source : 87ed9356aa23ae83762a887cf12ba1f466e7bf61
The stack object might be a CCW and we want to make it impossible to get a CCW's global. Now the caller has to supply a same-compartment global object, so we no longer rely on getting the CCW's global.
Right now consumers can't know when the parent process has finished talking
to the permission manager. It would be nice to enable consumers to depend
on the status of the asynchronous task using a promise.
Right now consumers can't know when the parent process has finished talking
to the permission manager. It would be nice to enable consumers to depend
on the status of the asynchronous task using a promise.
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : intermediate-source : 7f4cc96fae1212cb2220770ac7311b9cc51af744
extra : absorb_source : 7c71a5994c26c2a1e34b291947a49ac5b3d633cb
extra : source : dc7ec17179d1961d91b897cec9f409786363ec9e
extra : histedit_source : f7c7a935e72af65446c2abc502744a066a6e2ae5%2C5cd3235724af3e5f22b772de171cea735ec4c047
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : intermediate-source : 46a6f9d0773ba2d756d8801cee79bfa994165d44
extra : absorb_source : a725a095946946797fd4f3abe6461e810b15d899
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : 958212e804df7f9e1be6af182e73edc956b9a576
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : source : dc7ec17179d1961d91b897cec9f409786363ec9e
extra : histedit_source : 285a99038c6731fed427cd8bc783b65f56e34ebb
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : source : e3bbc87b71af2f2ce1fa8bdf2cf26857c071ba5e
extra : histedit_source : dc1c7c8015e0443eed218f826fda9f5b38b3e062%2C4cfa2f90104ca3e907607d884ac86f73ad4995bf
With the parent sending a snapshot of its preference state at content process
startup, we're guaranteed to have the full set of built-in preferences in the
shared map at initialization time, so there's no need to load them again.
This also applies to static preference default values, so we skip setting
those, as well.
However, we do need to make sure that we update static preference cache
entries whose default values don't match the value in the shared map, since
they may have been changed by user preference files. In order to deal with
that, we iterate over all preferences in the map, and dispatch callbacks for
any that have user values.
MozReview-Commit-ID: DlRUbg7Qor3
--HG--
extra : rebase_source : 93cad19e27d3aaf5d4cad358cdebd6d80b76f668
extra : absorb_source : 06cb8911c92b66f8863b5e184d88b923cdbd6adc
This adds an additional file descriptor to the set sent at content process
startup, for the read-only preference map that we share between all content
processes. This forms the base set of preferences. The other preferences FD
contains changes that the content process will need to apply on top of the
snapshot.
MozReview-Commit-ID: 6hc0HIxFmHg
--HG--
extra : rebase_source : f5de7462438e33cf4983be3fcef3c781c25ec492
extra : absorb_source : 9f9861546fc0b11333e575bb3c164dfe07575d99
This class allows one read-write copy of a map in the parent process to share
data with multiple read-only copies in child processes. The maps only hold
onto data as structured clone blobs, and deserialize them each time a key is
read.
This commit only provides the bare-bones data structures. Follow-ups will add
bindings, change events, and automatic flushes.
MozReview-Commit-ID: LimwfmFBNOi
--HG--
extra : rebase_source : e43985c39bd1cfd05a2ad536b0d7f74db494a753
extra : source : c27295337b4c16e2a178106a3aa873d2a0e5a1f4
This class allows one read-write copy of a map in the parent process to share
data with multiple read-only copies in child processes. The maps only hold
onto data as structured clone blobs, and deserialize them each time a key is
read.
This commit only provides the bare-bones data structures. Follow-ups will add
bindings, change events, and automatic flushes.
MozReview-Commit-ID: LimwfmFBNOi
--HG--
extra : rebase_source : a6959c9f3186af7252ac2899f6801d5e02b62222
Tiberius Oros
Haik Aftandilian
Andrew McCreight
Ehsan Akhgari
Andrea Marchesini
Jed Davis
Gabriele Svelto
Andreas Farre
Daniel Holbert
Brian Hackett
Adrian Wielgosik
Cosmin Sabou
Zibi Braniecki
Coroiu Cristina
Kartikaya Gupta
Kris Maglione
Jan de Mooij
Bogdan Tara
Brindusan Cristian
Margareta Eliza Balazs
Ben Kelly