1149998 - HTMLElement#mozSetFileArray throws error on CPOW referenced element

Status: RESOLVED WONTFIX

(Core :: DOM: Content Processes, defect)

Description

[Andreas Tolfsen ❲:ato❳]

Calling the chrome-only mozSetFileArray method on a CPOW-wrapped element reference from content space in chrome space, throws the following error:

     Error: Permission denied to access property Symbol.iterator No traceback available

Chrome space:

      mm.addMessageListener("setElementValue", function(msg) {
        let val = msg.data.value;
        let el = msg.objects.element;

        Cu.importGlobalProperties(["File"]);
        let fs = Array.prototype.slice.call(el.files);
        let f = new File(val);
        fs.push(file);
        el.mozSetFileArray(fs);
      }.bind(this);

Content space:

      let el = /* locate <input type=file multiple> element */;
      sendSyncMessage("setElementValue", {value: "/home/ato/testfile"}, {element: el});

The above example works fine without e10s enabled.  As a workaround I can use SpecialPowers in content space to elevate the privileges of the element, but this seems like a hack.

Comment 1

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

For the mochitests I've retrofitted for mozSetFileArray, I've been using the messageManager to send the File objects to the content-process script explicitly, instead of using CPOWs.  (And then using SpecialPowers to call mozSetFileArray, but that part could also be a frame script, in principle.)  That looks as if it should work for the code in comment #0, at least.

More generally, my understanding is that CPOWs are meant as a temporary measure, due to both performance and security drawbacks, and there's a desire to eventually get rid of them.  So I'd suspect there isn't much interest in adding more features to CPOWs unless it were important for making add-ons e10s-capable.  (I can't speak for the people who make the actual decisions about these things, of course.)

Comment 2

[Jonathan Griffin (:jgriffin)]

I'm running into this problem now that we're removing SpecialPowers from Marionette.  From jld's comments, it looks like I may be able to create the File objects in the parent process, shuttle them to the frame script via the message manager, and then use mozSetFileArray.  I'll try that and see how it goes.

Comment 3

[Andreas Tolfsen ❲:ato❳]

(In reply to Jonathan Griffin (:jgriffin) from comment #2)
> I'm running into this problem now that we're removing SpecialPowers from
> Marionette.  From jld's comments, it looks like I may be able to create the
> File objects in the parent process, shuttle them to the frame script via the
> message manager, and then use mozSetFileArray.  I'll try that and see how it
> goes.

See also my comment in testing/marionette/listener.js:
https://dxr.mozilla.org/mozilla-central/source/testing/marionette/listener.js?from=marionette/listener.js#1541

Comment 4

[Jonathan Griffin (:jgriffin)]

(In reply to Jed Davis [:jld] {UTC-7} from comment #1)
> For the mochitests I've retrofitted for mozSetFileArray, I've been using the
> messageManager to send the File objects to the content-process script
> explicitly, instead of using CPOWs.  (And then using SpecialPowers to call
> mozSetFileArray, but that part could also be a frame script, in principle.) 
> That looks as if it should work for the code in comment #0, at least.
> 
Yes, I tried it and this works on both e10s and non-e10s.

Comment 5

[Jens Stutte [:jstutte]]

If ever this is still relevant, shouldn't this be more DOM: Core ?

Comment 6

[Andrew McCreight [:mccr8]]

CPOW functionality was implemented in DOM: Content Processes code, so this is the right component, however CPOWs are gone.