565843 - Provide a path between Canvas and the File API

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, defect)

Description

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Should the load really take a File instead of a Blob?

And what exactly would mozSaveFile do?

Comment 2

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

(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.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> 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?

Comment 4

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(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 :-)

Comment 6

[Arun Ranganathan]

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/

Comment 7

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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

Comment 8

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Add mozGetAsFile(filename, type) to <canvas>

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.

Comment 9

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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

Comment 10

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Test

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.

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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])

Comment 12

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Consolidated patch

Comment 13

[Doug Turner (:dougt)]

happy to take a patch, but not blocking.

Comment 14

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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

Comment 15

[Doug Turner (:dougt)]

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 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 17

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Attachment: Patch

Fixing a couple minor nits.

Comment 18

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

http://hg.mozilla.org/mozilla-central/rev/e94fe7c8ecde

Comment 19

[Eric Shepherd [:sheppy]]

Now documented, with an example:

https://developer.mozilla.org/en/DOM/HTMLCanvasElement

And mentioned on the Fx4 for developers page.