E.g. provide: void mozLoadFile(in File file) File mozSaveFile(in string type) on CanvasRenderingContext2D. Where for type we accept image/png and any other encoders we have lying around and are willing to provide and throw appropriately on unrecognized types in both directions.

Should the load really take a File instead of a Blob? And what exactly would mozSaveFile do?

(In reply to comment #1) > Should the load really take a File instead of a Blob? If it took a Blob how would it know what format the image is? > And what exactly would mozSaveFile do? Export the contents of the canvas into the requested image format, or throw if that's not possible.

> If it took a Blob how would it know what format the image is? The magic number at the start of the data, no? That's what we do anyway; imagelib completely ignores MIME metadata. > Export the contents of the canvas into the requested image format, But a File has a whole bunch of stuff like a filename, etc. Where will that come from? For the output end, I agree it might be good to have a type tag; there has been talk of typed Blobs on the list recently, right?

In the latest drafts, Blobs now have .type and .url, so we should return Blobs

(grumble Blob grumble) mozLoadFile doesn't actually make sense to me for Canvas 2D -- there's no way to get the dimensions of the image beforehand, for example, so there's no way to resize the canvas to the appropriate dimensions. If this were some kind of magic method that did all that, it would be a little too magic. Seems like what we want is really 'img = new Image(data)'. mozSaveFile seems fine, though I would call it toBlob (like we have toDataURL). (Actually, I think it should be toDataChunk, but we can have that discussion after sicking/jst/etc. and I talk :-)

We may gain some advantages by creating a new object ("DataChunk"), per Vlad's proposal (originally made here: https://www.khronos.org/webgl/public-mailing-list/archives/1005/msg00062.html), or we could decide that File and Blob shouldn't have an inheritance relationship. Either way, toBlob (or toDataChunk) makes sense. The current File draft is here: http://dev.w3.org/2006/webapi/FileAPI/

Not working on this at the moment because of the unresolved issues on how to do this.

This patch adds a mozGetAsFile (we can call it mozToFile, or whatever, I really don't care) method to <canvas> that returns the contents of the canvas as a DOMFile, following the same rules as toDataUrl about the type. The giant blob of tests scares me so I didn't write a test for it yet, but I will later this week. I would appreciate speedy reviews as I'd like to get this into 2.0.

You can add tests separate from test_canvas (and probably should) -- there are other one-off tests in that directory.

This tests a few quick things. The test that <canvas>.toDataURL == <canvas>.mozGetAsFile().getAsDataURL() covers almost everything of interest, I think, but let me know if I should add more.

Two notes: 1. The destructor of nsDOMFile needs to be virtual. With that, all tests pass. 2. We need to sanitize the file name somehow to prevent the page from saying mozGetAsFile("/etc/passwd") because other internal code may rely on the value being of MozFullPath. Maybe we should just give the file a name that isn't a valid filename at all (something with an exclamation point or something) or hardcode a name (canvas.[jpg|png|etc])

happy to take a patch, but not blocking.

We need this patch to implement the capture picker in fennec.

review, then request approval2.0. also -- why not just use a native dialog? isn't that the least amount of risk at this point?

Comment on attachment 472884 [details] [diff] [review] Consolidated patch I don't have an opinion of what fennec should use. However this is a great feature that I think is worth exposing to web developers. Feel free to take my sr as an r if that helps.

Fixing a couple minor nits.

Now documented, with an example: https://developer.mozilla.org/en/DOM/HTMLCanvasElement And mentioned on the Fx4 for developers page.