1122855 - [e10s] SessionStore: use IPC blobs to restore <input type="file"> instead of |value| setter

Status: NEW

(Firefox :: Session Restore, defect)

Description

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

When SessionStore restores a file input element in e10s mode, it should construct a DOM File in the parent, send it to the child as an IPC blob, and use the chrome-only method to be added in bug 1068838 to attach it to the element.  Currently it uses the input element's |value| setter, which tries to access the file directly from the content process, which will conflict with sandboxing.

See also the penultimate sentence of bug 1068838 comment #1.

Comment 1

[Tim Taubert [:ttaubert] (inactive)]

This sounds like a bad idea to me. Currently we store the file name only, which is basically a link to the file. The file might be huge and have changed in the meantime while Firefox was closed. Storing the blob might lead to uploading a stale file and/or blow up sessionstore.js to enormous sizes.

How hard would it be to have some kind of privileged API to set a file input's value?

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

Oh, wait. I think I got this all wrong. You're suggesting to still only store the file name in sessionstore.js but instead of setting input.value create a DOMFile and send that.

I can see that this would work. Would there be a huge overhead if the file itself is huge? Or do we share those blobs between processes somehow?

Comment 3

[Jed Davis [:jld] ⟨⏰|UTC-7⟩ ⟦he/him⟧]

(In reply to Tim Taubert [:ttaubert] from comment #2)
> Oh, wait. I think I got this all wrong. You're suggesting to still only
> store the file name in sessionstore.js but instead of setting input.value
> create a DOMFile and send that.

Yes; I didn't mean to suggest any change to the actual on-disk storage, just how it reconstructs the form state.

> I can see that this would work. Would there be a huge overhead if the file
> itself is huge? Or do we share those blobs between processes somehow?

The chrome script File constructor / File::CreateFromFile creates an object that references the file, but doesn't immediately read it into memory.  Sending it to the child creates an IPC actor that can be used to open and read the file, which is how the e10s file picker already works.

Comment 4

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Jed Davis [:jld] from comment #3)
> The chrome script File constructor / File::CreateFromFile creates an object
> that references the file, but doesn't immediately read it into memory. 
> Sending it to the child creates an IPC actor that can be used to open and
> read the file, which is how the e10s file picker already works.

Great, thanks for clarifying! Let's do it.