In order to be able to reasonably debug error results from things like
JSWindowActor.sendQuery, we need to be able to clone errors across process
boundaries, so that they can be propagated to the caller that initiated a
query. The standard for the structured clone algorithm does not allow cloning
errors directly, so this patch instead adds a chrome-only wrapper object which
supports structured clone writing, and on reading, automatically decodes to
the error object it wraps. Callers who wish to clone an Error or Exception
object simply need to wrap it in a ClonedErrorHolder before sending.
Differential Revision: https://phabricator.services.mozilla.com/D50881
--HG--
extra : moz-landing-system : lando
The change to moz.build unveiled a couple unified build issues that I also had
to fix.
Depends on D55365
Differential Revision: https://phabricator.services.mozilla.com/D55366
--HG--
extra : moz-landing-system : lando
this way, preferences cant be modified by an extension, and they're
locked down in root-owned files.
Pledge promises files consist of a promise by line, are read first from
/etc/MOZ_APP_NAME/pledge.${processtype} (allowing overriding by a local
root if needed), and if not found
/usr/local/lib/MOZ_APP_NAME/browser/defaults/preferences is used, which
is where the OpenBSD packaging system will install the defaults.
Differential Revision: https://phabricator.services.mozilla.com/D51385
--HG--
extra : moz-landing-system : lando
Code outside of BrowserParent should just get the LayersId from a getter
and not worry about RenderFrame.
Differential Revision: https://phabricator.services.mozilla.com/D33562
--HG--
extra : rebase_source : 63f9f9680a7cb16a18d9e56999e02a124aa63429
extra : source : e86839ca63260b09184755c98890fa8abf371530
extra : histedit_source : 34333f5f78ecf9b4f3e12c6175a6e81724a41fb2
This commits adds EffectsInfo for tracking graphical effects
that are applied to a remote browser's ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D31471
--HG--
extra : rebase_source : 5c4cda4019095dbd00aa3bca2edff0dbd16e5ca8
extra : intermediate-source : b4d5865e33079a36f535501293f8aaec8b6bcf64
extra : source : e8e3d2d76d860c76ee351c8b10ed488fdac2d9fc
RemoteBrowser is a common interface between the chrome/content process cases for nsFrameLoader,
that allows us to abstract IPC details away. BrowserHost is a concrete implementation for
the chrome process, while BrowserBridgeHost implements the content process case.
Differential Revision: https://phabricator.services.mozilla.com/D31438
--HG--
extra : source : eadeacbe44838a0db21d5f535fd14bfd62455a22
RemoteBrowser is a common interface between the chrome/content process cases for nsFrameLoader,
that allows us to abstract IPC details away. BrowserHost is a concrete implementation for
the chrome process, while BrowserBridgeHost implements the content process case.
Differential Revision: https://phabricator.services.mozilla.com/D31438
--HG--
extra : rebase_source : 3518e45799a46f9bef57a36049fd7ae10f03aee6
extra : histedit_source : c8ea0b064234163284b9a161523c6bb2b6cba6c2
This adds a single new method, which acts like sendAsyncMessage, but
also returns a promise. This promise is fulfilled when the promise
returned from the receiveMessage callback is resolved.
```
partial interface JSWindowActor {
[Throws]
Promise<any> sendQuery(DOMString messageName,
optional any obj,
optional any transfers);
}
```
Differential Revision: https://phabricator.services.mozilla.com/D27809
--HG--
extra : moz-landing-system : lando
This devirutalizes a bunch of methods, and moves the entire implementation into
`Content{Parent,Child}` proper. The only purpose left for these types is as a
collection of interfaces and an IID for casting. They should likely be removed
entirely in a follow-up.
Depends on D20552
Differential Revision: https://phabricator.services.mozilla.com/D20553
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
This devirutalizes a bunch of methods, and moves the entire implementation into
`Content{Parent,Child}` proper. The only purpose left for these types is as a
collection of interfaces and an IID for casting. They should likely be removed
entirely in a follow-up.
Depends on D20552
Differential Revision: https://phabricator.services.mozilla.com/D20553
--HG--
extra : moz-landing-system : lando
This actor won't be being used anymore, and acts only as a maintenance burden
for people working on this code (which we're doing pretty often these days!).
Differential Revision: https://phabricator.services.mozilla.com/D20549
--HG--
extra : moz-landing-system : lando
This commit adds a PRemoteFrame actor which is managed by PBrowser. It will
be created in a child process nsFrameLoader when loading a remote subframe.
This actor will mostly just bounce messages from a nsFrameLoader in the child
process to the actor in the parent process which will redirect the messages
to the TabParent of the remote subframe.
The piece in the parent actor to create the proxied PBrowser actors is
deferred to the next commit.
Differential Revision: https://phabricator.services.mozilla.com/D17442
--HG--
extra : source : e72d9d31a8bc15e0d3e17d3bdae0b5717465c4b9
extra : intermediate-source : 12d7dba3473315edbdc2d73e3febec3ca9e987ae
This is needed because early in a content process's lifecycle, NeckoParent may
not have been created yet. This leads to issues when trying to redirect into a
fresh process which hasn't performed network loads yet. By sending the message
over PContent, we can be sure the APIs are available.
Differential Revision: https://phabricator.services.mozilla.com/D15608
--HG--
extra : moz-landing-system : lando
This logging topic will output the topic of MEssageManager data at log
level 4 (debug); and will output the entire content of the data at level
5 (verbose).
--HG--
extra : histedit_source : 7be60b456a1652f9a9985fd4a01571b207a5f9e6
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
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 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
Add the first version of the IPDL-JS API, which allow chrome JS to load IPDL files and use them to communicate accross Content processes.
See IPDLProtocol.h for more information regarding how to use the API.
Differential Revision: https://phabricator.services.mozilla.com/D2116
--HG--
rename : ipc/moz.build => ipc/ipdl_new/moz.build
extra : moz-landing-system : lando
At the moment this isn't actually async because we immediately require
the pid and block on launch anyway. It also crashes the entire browser
on otherwise recoverable launch errors, because code that wants the pid
isn't set up to handle that operation failing.
MozReview-Commit-ID: 5favGu34QCv
--HG--
extra : rebase_source : 3c81c53e1eb8ead353ef3477ed3ceea0f5edcbbe
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : intermediate-source : 434106f1b75e3ba900912f261bd22a1b7f5c931d
extra : absorb_source : 647ad37590448ad3c1eb8eb512bf671f262fa96e
extra : source : 68bb03c63b3cee1d47cbddfd3abf919f5783c04b
extra : histedit_source : 2228a9f8395929f5072a3c5ebda6ae3221e4a62d
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : source : 68bb03c63b3cee1d47cbddfd3abf919f5783c04b
This is based on the SharedStringMap that's currently used for shared memory
string bundles.
When the parent process is ready to launch its first content process, it
creates a snapshot of the current state of the preference database, maps that
as read-only, and shares it with each content process. Look-ups in the
snapshotted map are done entirely using data in the shared memory region. It
doesn't require any additional per-process state data.
MozReview-Commit-ID: BdTUhak7dmS
--HG--
extra : rebase_source : e7cb96dd52380f2ed2fbd79b4e157e4efab65cb0
extra : absorb_source : ed95ed85388875353458eb65e41727e606ebf097
This is the first basic implementation of a shared-memory key-value store for
JS message managers. It has one read-write endpoint in the parent process, and
separate read-only endpoints for each child-process message manager.
Changes to the parent endpoint are broadcast to the children as snapshots.
Each snapshot triggers a "change" event with a list of changed keys.
It currently has the following limitations:
- It only supports basic structured clone data. There's no support for blobs,
input streams, message ports... Blob support will be added in a follow-up
patch.
- Changes are currently only broadcast to child endpoints when flush() is
explicitly called in the parent, or when new child processes are launched.
In a follow-up, this will be changed to automatically flush after changes
when the event loop is idle.
- All set operations clone their inputs synchronously, which means that
there's no trivial way for callers to batch multiple changes to a single key
without some additional effort. It might be useful to add a
delayed-serialization option to the .set() call in a follow-up, for callers
who are sure they know what they're doing.
MozReview-Commit-ID: IM8a3UgejXU
--HG--
extra : rebase_source : 66c92d538a5485349bc789028fdc3a6806bc5d5a
extra : source : 2ebaf5f8c6055b11b11d7ec334d54ee941115d48
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 is the first basic implementation of a shared-memory key-value store for
JS message managers. It has one read-write endpoint in the parent process, and
separate read-only endpoints for each child-process message manager.
Changes to the parent endpoint are broadcast to the children as snapshots.
Each snapshot triggers a "change" event with a list of changed keys.
It currently has the following limitations:
- It only supports basic structured clone data. There's no support for blobs,
input streams, message ports... Blob support will be added in a follow-up
patch.
- Changes are currently only broadcast to child endpoints when flush() is
explicitly called in the parent, or when new child processes are launched.
In a follow-up, this will be changed to automatically flush after changes
when the event loop is idle.
- All set operations clone their inputs synchronously, which means that
there's no trivial way for callers to batch multiple changes to a single key
without some additional effort. It might be useful to add a
delayed-serialization option to the .set() call in a follow-up, for callers
who are sure they know what they're doing.
MozReview-Commit-ID: IM8a3UgejXU
--HG--
extra : rebase_source : 8e8b7891ca48e61b2d6ba3c05912064a909d9698
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
This class implements a shared memory key-value store that fits into a single
memory mapped segment. All of the runtime data for its instances are stored in
the shared memory region, which means that memory overhead for each instance
in each process is only a few bytes.
Importantly, the key and value strings returned by this class are also
pointers into the shared memory region, which means that once an instance is
created, its memory cannot be unmapped until process shutdown.
For the uses I intend to put it to, this is a reasonable constraint. If we
need to use it for shorter-lived maps in the future, we can add an option to
return non-literal dependent strings that will be copied if they need to be
kept alive long term.
MozReview-Commit-ID: 5BwAaDsb7HS
--HG--
extra : rebase_source : b472fe628018f88a2c4d6b3de4b7143aeca55e14
extra : absorb_source : 5cdeb568cfd2b4a5a767191402e699e61e653b3b
This class allows us to map a read-write shared memory region, and then safely
remap it read-only, so that it can be shared with sandboxed content processes.
MozReview-Commit-ID: 2PJMQgOwA4V
--HG--
extra : rebase_source : c556cabfa7d379a91dc9ef7171ac0a7d7d8fb32e
extra : absorb_source : e78e304ed95891c694050f79a0bb5d40d11ee884
The probe is expired and there's no clear owner here so let's remove this
for now.
--HG--
extra : rebase_source : 51c332a790ce5081ce4645633991c3b9213a5d21
extra : source : 98d141e6d651b804cf35040a5c20be74b6fb6c7a
All prefs that need to be sent to a new content process are now put into the
shared memory segment, and they are identified by the pref name instead of an
index into a list. The old IPC used at process startup (in XPCOMInitData) is
removed.
Benefits:
- It removes the need for the early prefs list
(dom/ipc/ContentProcesses.{h,cpp}) and the associated checking, which is ugly
and often trips people up (e.g. bug 1432979, bug 1439406).
- Using prefnames instead of indices fixes some fragility (fixing bug 1419432).
- It fixes the problem of early prefs being installed as unlocked default
values even if they are locked and/or have user values.
MozReview-Commit-ID: FRIzHF8Tjd
Right now the only parameter will be sent via the IPC message is form URI.
IPC is triggered when a password field is focusd (See P2.)
MozReview-Commit-ID: J8lVwRhTFIr
--HG--
extra : rebase_source : b948cf1a719c9a06100c54f3eda526ea6f7cf848
Everything depending on the widget being gonk can go away, as well as
everything depending on MOZ_AUDIO_CHANNEL_MANAGER, which was only
defined on gonk builds under b2g/ (which goes away in bug 1357326).
--HG--
extra : rebase_source : 9f0aeeb7eea8417fa4e06d662d566d67ecaf2a24
Ciure Andrei
Kris Maglione
Emilio Cobos Álvarez
Jean-Yves Avenard
joshua stein
Srujana Peddinti
Edgar Chen
Agi Sferro
Daniel Varga
Ryan Hunt
Gurzau Raul
John Dai
Dorel Luca
Ehsan Akhgari
Brindusan Cristian
Mike de Boer
Nika Layzell
Barret Rennie
Alex Gaynor
Thomas Nguyen
Andreea Pavel
Christoph Kerschbaumer
Jan Varga
Oana Pop Rus
Kershaw Chang
Kyle Machulis
Tom Ritter
Jed Davis
shindli
Tristan Bourvon
Cosmin Sabou
Margareta Eliza Balazs
Stephen A Pohl
Nicholas Nethercote
Jeff Muizelaar
Andrea Marchesini
Sylvestre Ledru
DimiL
Stone Shih
Marco Castelluccio
Mike Hommey