a10d45c7d6de821757a365b8827691390b55a705: Bug 1358115 - Use IPCBlob in DataTransfer, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:16:50 +0200 - rev 567198
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1358115 - Use IPCBlob in DataTransfer, r=smaug
2577afd226ff64101e4ed3767d0abff83c34c9bd: Bug 1358113 - Use IPCBlob in File.createFromNsIFile/createFromFileName, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:16:50 +0200 - rev 567197
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1358113 - Use IPCBlob in File.createFromNsIFile/createFromFileName, r=smaug
a180e3f4de16aa456c8cd039805aa0924618d5c9: Bug 1358114 - Use IPCBlob in BlobURL, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:16:49 +0200 - rev 567196
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1358114 - Use IPCBlob in BlobURL, r=smaug
73f62ae76c08245b15223918602b6b9db31809a2: Bug 1358111 - Use IPCBlob in Entries API - part 2 - Entries API, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:16:49 +0200 - rev 567195
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1358111 - Use IPCBlob in Entries API - part 2 - Entries API, r=smaug
50518d6aa0fc7d2f476b065ff877c02d7ba0a36a: Bug 1358111 - Use IPCBlob in Entries API - part 1 - GetFilesHelper, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:16:49 +0200 - rev 567194
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1358111 - Use IPCBlob in Entries API - part 1 - GetFilesHelper, r=smaug
dec83a85f824c2afb541ecbda08dab6aa1abcff0: Bug 1358109 - Use IPCBlob in PFilePicker, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:16:49 +0200 - rev 567193
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1358109 - Use IPCBlob in PFilePicker, r=smaug
6e18a14aa213774f5c80ca72e0667b87654c7b80: Bug 1353629 - PBlob refactoring - part 15 - FileMediaResource is used for in-process blobURL, r=jwwang
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:41 +0200 - rev 567192
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 15 - FileMediaResource is used for in-process blobURL, r=jwwang
b93b33542bcf7baa6029df8e0bc7a822412fe0cc: Bug 1353629 - PBlob refactoring - part 14 - tests, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:41 +0200 - rev 567191
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 14 - tests, r=smaug
6586412c7f6494e5d9df0c8a24e31ec55f9ab2d4: Bug 1353629 - PBlob refactoring - part 13 - IPCBlobInputStream should support remote nsIAsyncInputStream, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:41 +0200 - rev 567190
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 13 - IPCBlobInputStream should support remote nsIAsyncInputStream, r=smaug 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().
3a2c881ccf419304a7b728a9433fb3065f76f40a: Bug 1353629 - PBlob refactoring - part 12 - nsInputStreamPump should use BufferedStreams, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:41 +0200 - rev 567189
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 12 - nsInputStreamPump should use BufferedStreams, r=smaug 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.
a2d2d49d3e5774f788787cd375e46a69be5cf011: Bug 1353629 - PBlob refactoring - part 11 - Comments, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:41 +0200 - rev 567188
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 11 - Comments, r=smaug
1c786e61d5c88e404cc47a2a92cea86028235ba2: Bug 1353629 - PBlob refactoring - part 10 - Make nsFileInputStream cloneable, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:41 +0200 - rev 567187
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 10 - Make nsFileInputStream cloneable, r=smaug This is important to avoid extra copy when IPCInputStreamStorage::GetStream() returns a file inputStream
04d9349c61846108e9b2b99b207adaecdd366042: Bug 1353629 - PBlob refactoring - part 9 - PBlob should use IPCStream in case it is dealing with an IPCBlobInputStream, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:40 +0200 - rev 567186
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 9 - PBlob should use IPCStream in case it is dealing with an IPCBlobInputStream, r=smaug 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.
cee81d4988a513ca5f98bd81d94214ea5697d70d: Bug 1353629 - PBlob refactoring - part 8 - FileReader should use nsIAsyncInputStream if available, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:40 +0200 - rev 567185
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 8 - FileReader should use nsIAsyncInputStream if available, r=smaug 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.
a1ff18334e6b81c5f8886feaf39610e790fcfc96: Bug 1353629 - PBlob refactoring - part 7 - IPCBlobInputStream must implement nsIAsyncInputStream, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:40 +0200 - rev 567184
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 7 - IPCBlobInputStream must implement nsIAsyncInputStream, r=smaug In order to retrieve data from an IPCBlobInputStream, it must be used as nsIAsyncInputStream.
8496fe603461e33bff5caf5b42509476c0488aac: Bug 1353629 - PBlob refactoring - part 6 - IPCBlobInputStream serialization, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:40 +0200 - rev 567183
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 6 - IPCBlobInputStream serialization, r=smaug IPCBlobInputStream must implement nsIIPCSerializableInputStream interface. When this is done, the child sends the internal ID of the IPCBlobInputStream to the parent.
8fd6cad1a8d9198d0c91a03aafb18126592d3e98: Bug 1353629 - PBlob refactoring - part 5 - IPCBlobInputStreamStorage, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:40 +0200 - rev 567182
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 5 - IPCBlobInputStreamStorage, r=smaug 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.
e9400156bf733aa1a928969529eea5d5e6ed7f98: Bug 1353629 - PBlob refactoring - part 4 - IPCBlobInputStream, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:40 +0200 - rev 567181
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
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.
e257576d44a4bcee8eef180c67f5f2318def5d90: Bug 1353629 - PBlob refactoring - part 3 - IPCBlob in ClonedMessageData, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:40 +0200 - rev 567180
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 3 - IPCBlob in ClonedMessageData, r=smaug 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.
989411dbd27c982f01d47f924bbe5e1d68b39dbd: Bug 1353629 - PBlob refactoring - part 2 - IPCStream must be available on PBackground, r=smaug
Andrea Marchesini <amarchesini@mozilla.com> - Mon, 24 Apr 2017 12:09:40 +0200 - rev 567179
Push 55472 by dmitchell@mozilla.com at Mon, 24 Apr 2017 14:13:19 +0000
Bug 1353629 - PBlob refactoring - part 2 - IPCStream must be available on PBackground, r=smaug In order to use IPCBlob in any IPC protocol, IPCStream must be available also on PBackground.
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip