On Sun, Aug 4, 2013 at 7:51 AM, Andrew Sutherland <[email protected]> wrote: > On 08/04/2013 01:48 AM, Jonas Sicking wrote: >> I think we might have an implementation bug right now so that when you >> use XHR to submit a Blob, we load that whole Blob into memory. That is >> something we should be able to fix though. No new APIs needed, someone >> just needs to flag this as an important issue. > > > Are you sure about this?
No. Hence the "I think" and the "might" above :-) > I had trouble finding any bugs and it appears that all Blob/File > implementations inherit from nsDOMFileBase which implements nsIXHRSendable. > XHR from a worker marshals the nsIDOMFile across to the main thread where a > fresh mozilla::dom::workers::file::Blob/File is created to wrap it. That > gets turned into an XPCVariant with type VTYPE_INTERFACE_IS. nsXMLHttpRequest > then keeps trying interfaces until it gets to nsIXHRSendable and the file's > GetInternalStream is called to produce an nsIInputStream. All of the > implementations look pretty straightforward; nsDOMMultipartFile creates a > multiplex stream, nsDOMFileFile creates a local stream, nsDOMMemoryFile > creates a byte input stream. The IPC RemoteBlob stuff also seems okay, but > it shouldn't be involved as far as I can tell. The issue is at the point when the nsIHttpChannel sends the POST data to the parent process. I.e. after all XHR code has run. I just don't know for sure that this case is handled correctly. If you are not seeing issues then probably not something to worry about. > If you think there's a subtle error where something breaks, I can do a run > with gdb and check what's actually happening. Or if I'm completely wrong > about the path the data is taking, please let me know! We used to have some code in the IPC code which would synchronously read the contents of input streams if needed. But I can't find that code any more so I don't know where to recommend putting a breakpoint to see if we hit it. Hopefully that means that the code is gone! >> The only tricky part with writing base64-encoded Blobs is that you >> probably don't want to base64 encode the whole Blob in one go. The >> FileHandle API would let you handle this, but it doesn't work on B2G >> yet. > > > Yeah, this is the other sadness I've had to work around. See my other post, > "[b2g] Writing large Blobs to DeviceStorage without getting OOM-killed > without getEditable, IndexedDB's mozCreateFileHandle being main-proc only?" > (https://groups.google.com/forum/#!topic/mozilla.dev.b2g/N8aHf8AN1mk) request > for confirmation on that. I think you're confirming it here, though! There are many ways that we should be handling this. The most direct one is to implement mozCreateFileHandle. Other ways is to implement a sandboxed filesystem API. But it'd also be nice to support some way for an application to incrementally create a file-backed Blob in such a way that data can be streamed into it. I think once we get a Stream primitive we can make that happen. I suspect none of that will happen in time for v1.2 though. But maybe 1.3. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
