Open Bug 1149998 Opened 5 years ago Updated 4 years ago

HTMLElement#mozSetFileArray throws error on CPOW referenced element

Categories

(Core :: DOM: Content Processes, defect)

defect
Not set

Tracking

()

People

(Reporter: ato, Unassigned)

Details

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.
OS: Linux → All
Hardware: x86 → All
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.)
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.
(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
(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.
Blocks: 1238095
No longer blocks: 1238095
You need to log in before you can comment on or make changes to this bug.