See e.g.http://hg.mozilla.org/mozilla-central/annotate/942ed5747b63/dom/mms/src/ril/MmsService.js#l323 We could get rid of this trivially with OS.File.writeAtomic.

Marking this as a mentored bug.

Were it possible to create a blob in javascript? I think that's what we really need to store the whole message into IndexedDb.

If we just want to move the code to off main thread file I/O with OS.File.writeAtomic, we do not need a Blob. But otherwise, yes, I am almost certain that |new Blob(array)| works, where |array| can be either a regular array or a typed array.

(In reply to David Rajchenbach Teller [:Yoric] from comment #3) > But otherwise, yes, I am almost certain that |new Blob(array)| works, where > |array| can be either a regular array or a typed array. You can't pass an ArrayBuffer directly to the Blob constructor. You have to always pass a JS array. But you can do something like |new Blob([arraybuffer])|. Hmm.. you might actually need to pass an ArrayBufferView. So something like |new Blob([new Int8Array(arraybuffer)])|. Sorry, the binary API is a mess :(

By the way, we shouldn't be doing file-io manually here. We should just create Blob objects and then save those in indexedDB along with the other MMS data. IndexedDB allows treating Blob data just like any other data, so you can do something like: objectStore.put({ type: "mms", smil: "...", to: ["+1234567"], attachments: [{ name: "foo", blob: myBlobObject }, { name: "bar", blob: myOtherBlobObject }]}) The indexedDB implementation will make sure to do all of the IO on a background thread.

I refer https://mxr.mozilla.org/mozilla-central/source/content/base/src/nsContentUtils.cpp#6087 for MmsBlobService::CreateBlob(...)

Comment on attachment 695568 [details] [diff] [review] Save MMS attachments as blob Review of attachment 695568 [details] [diff] [review]: ----------------------------------------------------------------- Jonas, could you help review this?

Comment on attachment 695568 [details] [diff] [review] Save MMS attachments as blob Review of attachment 695568 [details] [diff] [review]: ----------------------------------------------------------------- All of this really shouldn't be needed. We already support creating a Blob by simply doing |new Blob([data], { type: mimetype })|. What type is msg.parts[x].content? Is it a JS-array of bytes? If so you can do something like: data = new Uint32Array(msg.content.length); msg.content.forEach(function(v, index) { data[index] = v; }); blob = new Blob([data], { type: msg.headers["content-type"].media }); But of course even better would be if the MmsPduHelper created an Uint32Array directly rather than using a normal JS array of numbers. JS arrays of numbers is a terribly inefficient way of storing data so I'm a little bit worried about memory usage. Either way, there should be no need for the new MmsBlobService.

(In reply to Jonas Sicking (:sicking) from comment #11) > All of this really shouldn't be needed. We already support > creating a Blob by simply doing |new Blob([data], { type: > mimetype })|. I didn't find similar commit in the history, could you help pointing it out? Last time we talked about this, it was still an unimplemented request. We can definitely try again though.

Hmm.. you might be right that |new Blob| doesn't work in JS components yet. But it should require less code to make that work than what you are doing here. Basically you just need to hook up a Blob constructor the same way that the File constructor is hooked up [1][2]. You basically just need to call [3] to create the blob and then [4] to initialize it. [1] http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/loader/mozJSComponentLoader.cpp#290 [2] http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/loader/mozJSComponentLoader.cpp#238 [3] http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDOMBlobBuilder.cpp#154 [4] http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsDOMBlobBuilder.cpp#169

File a new Bug 825836 for support Blob in JS components.

Comment on attachment 699205 [details] [diff] [review] Save MMS attachments as blob Review of attachment 699205 [details] [diff] [review]: ----------------------------------------------------------------- Let's remove all file storing related code here. Shall we?

Comment on attachment 699729 [details] [diff] [review] Save MMS attachments as blob Review of attachment 699729 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/mms/src/ril/MmsService.js @@ +535,5 @@ > return; > } > + // Todo: Please add code for inserting msg into database > + // right here. > + // see bug id: 811252 - B2G MMS: implement MMS database Trailing space. Besides, it's fine to save a line break here, I think :) ::: dom/mms/src/ril/WspPduHelper.jsm @@ +2240,5 @@ > let content = Octet.decodeMultiple(data, contentEnd); > + if(content) { > + content = new Blob([content], > + {"type" : headers["content-type"].media}); > + } Please just have two distinct variables for different uses. And mind a space char after 'if'.

For mms merge to b2g18.

The entire set of clian's pushes was backed out for multiple reasons. https://tbpl.mozilla.org/?tree=Mozilla-B2g18&rev=a0b06192f882 1.) The tree rules are clear that you are not to land on top of bustage. At the time you pushed, both B2G Mn and B2G xpcshell had bustage from prior commits that hadn't been backed out yet. 2.) The tree rules are also clear that you are to watch your pushes for any bustage and handle them accordingly. mozilla-inbound is the ONLY tree where this rule does not apply. 3.) Even after the earlier bustage was backed out, something in one of your many pushes was causing further B2G Mn failures as shown in the log below. https://tbpl.mozilla.org/php/getParsedLog.php?id=20424173&tree=Mozilla-B2g18 4.) This isn't cause for backout by itself, but it is also strongly preferred to not push each commit individually as our build and testing resources are limited and doing so stretches them even thinner. Please limit your number of pushes as much as possible unless you have good reason for keeping them separate.