If a child-to-parent IPCBlob is more than 1mb, we end up using a pipe stream.
If that ipcBlob is sent to a different process, we need to implement asyncWait
correctly: we need to call the remoteStream->AsyncWait().
nsInputStreamPump should use the stream as nsIAsyncInputStream if available.
In order to do so, we need to wrap a BufferedStream around it.
MediaResource cannot use a simple sync nsIInputStream when BlobURL are involved
in the content process.
This patch will go away when I'll finishing the removing of PBlob. Currently,
when a PBlob is sent from child to parent, we use PMemoryStream in order to
recreate the inputStream on the parent side. PMemoryStream sends the data in
chunks.
But if PBlob is dealing with a IPCBlobInputStream, it doesn't have access to
the real data. In this case, we must send data using IPCStream. In this way,
Note that thisIPCBlobInputStream will send its ID, and the parent will take the
real inputStream from the IPCBlobInputStreamStorage. Note that I check the
size to be 1mb instead 0. No particular reasons, but better to avoid the use of
PMemoryStream for nothing.
Currently FileReader API uses a nsITransport. This is not needed if the
inputStream is a nsIAsyncInputStream already, and IPCBlobInputStream is always
a nsIAsyncInputStream.
Note that, we must create a bufferedStream in order to use ReadSegments in case
the remote inputStream, received by IPCBlobInputStream, is a FileInputStream.
This was not needed with nsITransport.
IPCBlobInputStream must implement nsIIPCSerializableInputStream interface.
When this is done, the child sends the internal ID of the IPCBlobInputStream to
the parent.
An IPCBlobInputStream can be sent back to the parent process (not implemented
in this patch). When this is done, we basically send only the internal ID.
From this ID, we can retrieve the original inputStream because any
IPCBlobInputStreamParent actor has previously registered it into a singleton:
IPCBlobInputStreamStorage.
So, if we have a IPCBlobInputStreamParent, we have an inputStream, and this
inputStream is known by IPCBlobInputStreamStorage. This will be useful in the
next patches.
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.
This is the first use of IPCBlob: ClonedMessageData.
ClonedMessageData is used for BroadcastChannel, MessagePort and any
postMessage() communication. This patch changes StructuredCloneData in order to
use IPCBlob instead of PBlob.
BroadcastChannel has a custom way to manage Blobs because when the parent
receives them from a content process, it must send them to any other
BroadcastChild actor duplicating the serialization.
This first patch introduces the basic idea of the refactoring. Instead of
having a PBlob protocol, here we have a simple IPC struct: IPCBlob.
When a Blob is sent to a different process, we move an IPCBlob struct with
type, size, some specific File properties, and an inputStream as IPCStream.
For testing IMEContentObserver, text change, selection change and position change notifications should be exposed to JS with nsITextInputProcessorNotification.
MozReview-Commit-ID: 3PUhKXRwnAn
--HG--
extra : rebase_source : fce7a73683a2d4811070453629ef48d3ad15c8c8
The dialog functionality of the non-standard window.find API has been broken
with e10s since it shipped, and bug 1182569 or bug 1232432 (or both) have
broken it for non-e10s.
This patch remove showDialog support entirely, for both e10s and non-e10s,
in a more deliberate way. We now ignore the argument.
MozReview-Commit-ID: 1CTzgEkDhHW
--HG--
extra : rebase_source : 9aa9623ef649fb2c42ad22738130c361acf6b8cc
IMEContentObserver can store pointer of IMENotificationRequests of its mWidget. Therefore, it can check the requests dynamically when it receives content change or layout change.
This patch makes IMEContentObserver stores IMENotificationRequests as pointer and check it at every change notification received. Additionally, notification request may be changed due to focus move or something. Therefore, this patch makes IMEContentObserver and IMEContentObserver::IMENotificationSender() check if the notifications are still necessary.
MozReview-Commit-ID: 2uU2wN15D8v
--HG--
extra : rebase_source : 6086e0293343632df43087c767ad00521e764476
IMEContentObserver may need to change notifications to send when TextInputProcessor begins input transaction. In current design, IMEContentObserver needs to retrieve IMENotificationRequests at every change. However, if nsIWidget returns a reference to its IMENotificationRequests, IMEContentObserver can call it only once.
For that purpose, this patch changes nsIWidget::GetIMENotificationRequests() to nsIWidget::IMENotificationRequestsRef() and make it return |const IMENotificationRequests&|. However, if the lifetime of the instance of IMENotificationRequest is shorter than the widget instance's, it's dangerous. Therefore, it always returns TextEventDispatcher::mIMENotificationRequests. TextEventDispatcher's lifetime is longer than the widget. Therefore, this guarantees the lifetime.
On the other hand, widget needs to update TextEventDispatcher::mIMENotificationRequests before calls of nsIWidget::IMENotificationRequestsRef(). Therefore, this patch makes TextEventDispatcher update proper IMENotificationRequests when it gets focus or starts new input transaction and clear mIMENotificationRequests when it loses focus.
Note that TextEventDispatcher gets proper requests both from native text event dispatcher listener (typically, implemented by native IME handler class) and TextInputProcessor when TextInputProcessor has input transaction because even if TextInputProcessor overrides native IME, native IME still needs to know the content changes since they may get new input transaction after that.
However, there may not be native IME handler in content process. If it runs in Android, PuppetWidget may have native IME handler because widget directly handles IME in e10s mode for Android. Otherwise, native IME handler is in its parent process. So, if TextInputHandler has input transaction in content process, PuppetWidget needs to behave as native event handler. Therefore, this patch makes PuppetWidget inherit TextEventDispatcherListener and implements PuppetWidget::IMENotificationRequestsRef().
MozReview-Commit-ID: 2SW3moONTOX
--HG--
extra : rebase_source : d2634ada6c33dbf7a966fadb68608411ee24bfab
1. using media::TimeUnit to save some typing.
2. replace TimeUnit() with TimeUnit::Zero().
3. replace TimeUnit::FromXXX(0) with TimeUnit::Zero().
4. replace TimeUnit::FromMicroseconds(std::numeric_limits<int64_t>::max()) with TimeUnit::FromInfinity().
5. replace some uses of int64_t with TimeUnit.
6. replace t > TimeUnit() with t.IsPositive().
MozReview-Commit-ID: 6hC94PXx86i
--HG--
extra : rebase_source : 1ea3b409e6ec12915f3e1a00359d6ff4152c8917
extra : intermediate-source : e31a12ad0e7a4840119036f261ed17eaaff85734
extra : source : ae07ee48000c4a52da0e4fd502b4d690ec51ce1f
media::TimeUnit can take its place. We don't want 2 things for the same purpose to cause confusion.
MozReview-Commit-ID: 3z6hbgXFsxP
--HG--
extra : rebase_source : 0b472e351abdc48e337aaf645ae8be467e8a300f
extra : intermediate-source : 4e2156ec04fd30af6cf59adfd1390cf67f411d4c
extra : source : bf5b035c7041a892517373dd566d2a7d7ec60c72
