Closed
Bug 1149998
Opened 9 years ago
Closed 2 years ago
HTMLElement#mozSetFileArray throws error on CPOW referenced element
Categories
(Core :: DOM: Content Processes, defect)
Core
DOM: Content Processes
Tracking
()
RESOLVED
WONTFIX
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.
Reporter | ||
Updated•9 years ago
|
OS: Linux → All
Hardware: x86 → All
Comment 1•9 years ago
|
||
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•9 years ago
|
||
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.
Reporter | ||
Comment 3•9 years ago
|
||
(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•9 years ago
|
||
(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•2 years ago
|
||
If ever this is still relevant, shouldn't this be more DOM: Core ?
Flags: needinfo?(bugs)
Comment 6•2 years ago
|
||
CPOW functionality was implemented in DOM: Content Processes code, so this is the right component, however CPOWs are gone.
Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(bugs)
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•