2014-06-11 09:44:13 +04:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* vim: set ts=2 et sw=2 tw=80: */
|
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this file,
|
|
|
|
* You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
|
|
|
|
include protocol PBrowser;
|
|
|
|
include protocol PContent;
|
|
|
|
include protocol PJavaScript;
|
2016-09-21 13:27:26 +03:00
|
|
|
include protocol PFileDescriptorSet;
|
2017-03-14 14:28:58 +03:00
|
|
|
include protocol PChildToParentStream;
|
2017-03-14 14:29:43 +03:00
|
|
|
include protocol PParentToChildStream;
|
Bug 1353629 - PBlob refactoring - part 4 - IPCBlobInputStream, r=smaug
IPCBlobInputStream is a new type of nsIInputStream that is used only in content
process when a Blob is sent from parent to child. This inputStream is for now,
just cloneable.
When the parent process sends a Blob to a content process, it has the Blob and
its inputStream. With its inputStream it creates a IPCBlobInputStreamParent
actor. This actor keeps the inputStream alive for following uses (not part of
this patch).
On the child side we will have, of course, a IPCBlobInputStreamChild actor.
This actor is able to create a IPCBlobInputStream when CreateStream() is
called. This means that 1 IPCBlobInputStreamChild can manage multiple
IPCBlobInputStreams each time one of them is cloned. When the last one of this
stream is released, the child actor sends a __delete__ request to the parent
side; the parent will be deleted, and the original inputStream, on the parent
side, will be released as well.
IPCBlobInputStream is a special inputStream because each method, except for
Available() fails. Basically, this inputStream cannot be used on the content
process for nothing else than knowing the size of the original stream.
In the following patches, I'll introduce an async way to use it.
2017-04-24 13:09:40 +03:00
|
|
|
include protocol PIPCBlobInputStream;
|
2014-06-11 09:44:13 +04:00
|
|
|
|
|
|
|
include DOMTypes;
|
|
|
|
include JavaScriptTypes;
|
Bug 1353629 - PBlob refactoring - part 4 - IPCBlobInputStream, r=smaug
IPCBlobInputStream is a new type of nsIInputStream that is used only in content
process when a Blob is sent from parent to child. This inputStream is for now,
just cloneable.
When the parent process sends a Blob to a content process, it has the Blob and
its inputStream. With its inputStream it creates a IPCBlobInputStreamParent
actor. This actor keeps the inputStream alive for following uses (not part of
this patch).
On the child side we will have, of course, a IPCBlobInputStreamChild actor.
This actor is able to create a IPCBlobInputStream when CreateStream() is
called. This means that 1 IPCBlobInputStreamChild can manage multiple
IPCBlobInputStreams each time one of them is cloned. When the last one of this
stream is released, the child actor sends a __delete__ request to the parent
side; the parent will be deleted, and the original inputStream, on the parent
side, will be released as well.
IPCBlobInputStream is a special inputStream because each method, except for
Available() fails. Basically, this inputStream cannot be used on the content
process for nothing else than knowing the size of the original stream.
In the following patches, I'll introduce an async way to use it.
2017-04-24 13:09:40 +03:00
|
|
|
include ProtocolTypes;
|
2014-06-11 09:44:13 +04:00
|
|
|
include PTabContext;
|
|
|
|
|
|
|
|
using class IPC::Principal from "mozilla/dom/PermissionMessageUtils.h";
|
2014-10-29 21:11:00 +03:00
|
|
|
using mozilla::dom::TabId from "mozilla/dom/ipc/IdType.h";
|
2014-10-24 04:28:00 +04:00
|
|
|
using mozilla::dom::ContentParentId from "mozilla/dom/ipc/IdType.h";
|
2016-08-10 09:18:29 +03:00
|
|
|
using class mozilla::dom::MessagePort from "mozilla/dom/MessagePort.h";
|
|
|
|
using class mozilla::dom::ipc::StructuredCloneData from "mozilla/dom/ipc/StructuredCloneData.h";
|
2014-06-11 09:44:13 +04:00
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
namespace dom {
|
|
|
|
|
|
|
|
/*
|
|
|
|
* PContentBridge allows us to represent a parent/child relationship between two
|
|
|
|
* child processes. When a child process wants to open its own child, it asks
|
|
|
|
* the root process to create a new process and then bridge them. The first
|
|
|
|
* child will allocate the PContentBridgeParent, and the newly opened child will
|
|
|
|
* allocate the PContentBridgeChild. This protocol allows these processes to
|
|
|
|
* share PBrowsers and send messages to each other.
|
|
|
|
*/
|
2016-10-01 02:20:50 +03:00
|
|
|
nested(upto inside_cpow) sync protocol PContentBridge
|
2014-06-11 09:44:13 +04:00
|
|
|
{
|
|
|
|
manages PBrowser;
|
2016-09-21 13:27:26 +03:00
|
|
|
manages PFileDescriptorSet;
|
2014-06-11 09:44:13 +04:00
|
|
|
manages PJavaScript;
|
2017-03-14 14:28:58 +03:00
|
|
|
manages PChildToParentStream;
|
2017-03-14 14:29:43 +03:00
|
|
|
manages PParentToChildStream;
|
Bug 1353629 - PBlob refactoring - part 4 - IPCBlobInputStream, r=smaug
IPCBlobInputStream is a new type of nsIInputStream that is used only in content
process when a Blob is sent from parent to child. This inputStream is for now,
just cloneable.
When the parent process sends a Blob to a content process, it has the Blob and
its inputStream. With its inputStream it creates a IPCBlobInputStreamParent
actor. This actor keeps the inputStream alive for following uses (not part of
this patch).
On the child side we will have, of course, a IPCBlobInputStreamChild actor.
This actor is able to create a IPCBlobInputStream when CreateStream() is
called. This means that 1 IPCBlobInputStreamChild can manage multiple
IPCBlobInputStreams each time one of them is cloned. When the last one of this
stream is released, the child actor sends a __delete__ request to the parent
side; the parent will be deleted, and the original inputStream, on the parent
side, will be released as well.
IPCBlobInputStream is a special inputStream because each method, except for
Available() fails. Basically, this inputStream cannot be used on the content
process for nothing else than knowing the size of the original stream.
In the following patches, I'll introduce an async way to use it.
2017-04-24 13:09:40 +03:00
|
|
|
manages PIPCBlobInputStream;
|
2017-03-14 14:29:43 +03:00
|
|
|
|
|
|
|
child:
|
|
|
|
async PParentToChildStream();
|
2014-06-11 09:44:13 +04:00
|
|
|
|
2017-03-15 04:00:00 +03:00
|
|
|
child:
|
|
|
|
/**
|
|
|
|
* Sending an activate message moves focus to the child.
|
|
|
|
*/
|
|
|
|
async Activate(PBrowser aTab);
|
|
|
|
|
|
|
|
async Deactivate(PBrowser aTab);
|
|
|
|
|
|
|
|
async ParentActivated(PBrowser aTab, bool aActivated);
|
|
|
|
|
Bug 1353629 - PBlob refactoring - part 4 - IPCBlobInputStream, r=smaug
IPCBlobInputStream is a new type of nsIInputStream that is used only in content
process when a Blob is sent from parent to child. This inputStream is for now,
just cloneable.
When the parent process sends a Blob to a content process, it has the Blob and
its inputStream. With its inputStream it creates a IPCBlobInputStreamParent
actor. This actor keeps the inputStream alive for following uses (not part of
this patch).
On the child side we will have, of course, a IPCBlobInputStreamChild actor.
This actor is able to create a IPCBlobInputStream when CreateStream() is
called. This means that 1 IPCBlobInputStreamChild can manage multiple
IPCBlobInputStreams each time one of them is cloned. When the last one of this
stream is released, the child actor sends a __delete__ request to the parent
side; the parent will be deleted, and the original inputStream, on the parent
side, will be released as well.
IPCBlobInputStream is a special inputStream because each method, except for
Available() fails. Basically, this inputStream cannot be used on the content
process for nothing else than knowing the size of the original stream.
In the following patches, I'll introduce an async way to use it.
2017-04-24 13:09:40 +03:00
|
|
|
async PIPCBlobInputStream(nsID aID, uint64_t aSize);
|
|
|
|
|
2014-06-11 09:44:13 +04:00
|
|
|
parent:
|
|
|
|
sync SyncMessage(nsString aMessage, ClonedMessageData aData,
|
|
|
|
CpowEntry[] aCpows, Principal aPrincipal)
|
2015-09-10 23:50:58 +03:00
|
|
|
returns (StructuredCloneData[] retval);
|
2015-10-09 10:25:00 +03:00
|
|
|
|
|
|
|
async PJavaScript();
|
2016-09-21 13:27:26 +03:00
|
|
|
|
2017-03-14 14:28:58 +03:00
|
|
|
async PChildToParentStream();
|
2016-09-21 13:27:26 +03:00
|
|
|
|
2014-06-11 09:44:13 +04:00
|
|
|
both:
|
|
|
|
// Both the parent and the child can construct the PBrowser.
|
|
|
|
// See the comment in PContent::PBrowser().
|
2017-04-07 02:46:18 +03:00
|
|
|
async PBrowser(TabId tabId, TabId sameTabGroupAs,
|
|
|
|
IPCTabContext context, uint32_t chromeFlags,
|
2016-10-15 04:46:26 +03:00
|
|
|
ContentParentId cpId, bool isForBrowser);
|
2014-06-11 09:44:13 +04:00
|
|
|
|
2016-09-21 13:27:26 +03:00
|
|
|
async PFileDescriptorSet(FileDescriptor fd);
|
|
|
|
|
2016-04-09 16:50:59 +03:00
|
|
|
async AsyncMessage(nsString aMessage, CpowEntry[] aCpows,
|
|
|
|
Principal aPrincipal, ClonedMessageData aData);
|
2014-06-11 09:44:13 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
}
|
|
|
|
}
|