To prevent addons or other code to rapidly create and destroy content processes
under various conditions, we let the preallocated process manager to reuse short
lived content processes.
This environment variable works on both Windows and Linux for force-disabling
the content sandbox, and now does so on macOS as well.
The xpcshell tests force disable the sandbox because they do things like bind()
sockets, which is not compatible with the content sandbox. This is needed now
because bug 1358223 was force upgrading the sandbox from level 0 (disabled) to
level 1 on beta channel, which caused breakage.
MozReview-Commit-ID: 5DGxtoDLp0C
--HG--
extra : rebase_source : 87edd138e8b711eace5cb8103c67feae0361e148
MozReview-Commit-ID: A1lCqvbQYAF
There is no clean API-based solution to this, so instead I went grovelling
through the DCOM wire protocol and was able to write a function that converts
handler OBJREFs into standard OBJREFs.
See also:
https://msdn.microsoft.com/en-us/library/cc226801
--HG--
extra : rebase_source : a650055c4adda3a1d99262e47f2b463074c6b935
Every JS plugin is assigned a unique ID. When an instance of a JS plugin is created the
frame loader that we use to load the plugin's handler URI will create a special
TabContext. This TabContext causes the ContentParent to use the process for this specific
JS plugin (creating one if it hasn't already) when it creates the PBrowser actors.
This causes the iframes for all the instances of a specific JS plugin to be grouped in the
same process.
--HG--
extra : rebase_source : c39560bdf66cda1a005c7b823b3a46e4734878a4
extra : source : 9cba1db527c7eed4371c9f4caf96fd942608cab6
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : cd5a853c46a5cd334504b339bef8df30a3cabe51
If the "security.sandbox.content.level" preference is set to a value less than
1, all consumers will automatically treat it as if it were level 1. On Linux and
Nightly builds, setting the sandbox level to 0 is still allowed, for now.
MozReview-Commit-ID: 9QNTCkdbTfm
--HG--
extra : rebase_source : 1a26ffc5b9f80e6df4c37c23f506e907ba44053a
This event is no longer necessary, since checking nsITabParent.hasPresented is enough to know
if we need to blank out the tab or not.
MozReview-Commit-ID: 445XMqhorxC
--HG--
extra : rebase_source : 1a05de827502c409d979a621471978b08ce39fb2
Switching to Telemetry::ProcessID allows us to break out extension process data from the content process data.
--HG--
extra : rebase_source : ab334ad33b879dce373f810b452b73747ba82109
extra : source : 9cf5185e6d6fd15b1dd35b1552317ebd5ff258ed
Changes:
- remove code addressed by reviewer
- remove PContent.ipdl, PBrowser.ipdl, and ProcessPriorityManager code
that relates only to removed AudioChannelService methods
- correct test case listening to event from removed code
- remove useless test case files
MozReview-Commit-ID: I96nR8zTXJt
--HG--
extra : rebase_source : 127876c672744811c025ca55839ff2e8a06b1fce
This function is arguably nicer than calling NS_ProcessNextEvent
manually, is slightly more efficient, and will enable better auditing
for NS_ProcessNextEvent when we do Quantum DOM scheduling changes.
