function copy(str) {
Cc["@mozilla.org/widget/clipboardhelper;1"].
getService(Ci.nsIClipboardHelper).
copyString(str);
}
This seems not to fail (no exception thrown), but no data is copied to
the clipboard. I have also tried the more elaborate approach, to no
avail:
function copy(str_to_copy) {
let str = Cc["@mozilla.org/supports-string;1"].
createInstance(Ci.nsISupportsString);
str.data = str_to_copy;
let trans = Cc["@mozilla.org/widget/transferable;1"].
createInstance(Ci.nsITransferable);
trans.addDataFlavor("text/unicode");
trans.setTransferData("text/unicode", str, str_to_copy.length * 2);
let clip = Cc["@mozilla.org/widget/clipboard;1"].
getService(Ci.nsIClipboard);
clip.setData(trans, null, Ci.nsIClipboard.kGlobalClipboard);
}
Reading the clipboard data on the other hand works without any
problem, and the same |copy| function, when executed from the error
console, works perfectly.
Is there something specific about the xpcshell environment which could
cause this to fail? I could instead write the test as a chrome test
as well, but it sounds like over-kill...
Thanks!
--
Ehsan
<http://ehsanakhgari.org/>
> Is there something specific about the xpcshell environment which could
> cause this to fail? I could instead write the test as a chrome test
> as well, but it sounds like over-kill...
I suppose I wouldn't be terribly surprised if cut/paste expected a
window to be present, but it's rather weird that paste works but cut
doesn't.
You could debug the problem to see if something's silently breaking
(although I found the cut'n'paste code to be a bit scary when I last
poked at it), but it might be simplest to just write the test as a
mochi/chrome test and avoid the problem.
Justin
Hmm, I don't see anywhere in the Win32 clipboard API where a window
handle is necessary, but that might be possible at any rate.
> You could debug the problem to see if something's silently breaking
> (although I found the cut'n'paste code to be a bit scary when I last poked
> at it),
I did that, and for both pieces of code I traced the program until the
OleSetClipboard call and they both succeeded, without modifying the
contents of the native clipboard. I even compared the debugging
session alongside another debugging session with the code running as a
chrome test, and they both seemed similar!
I filed this bug https://bugzilla.mozilla.org/show_bug.cgi?id=475088
for the issue.
> but it might be simplest to just write the test as a mochi/chrome
> test and avoid the problem.
Yup, that's what I ended up doing.
Thanks for your help.
--
Ehsan
<http://ehsanakhgari.org/>
>Is there something specific about the xpcshell environment which could cause this to fail?
>
At a wild guess, lack of a message loop could cause this to fail.
--
Warning: May contain traces of nuts.
Yes, that seems like a logical explanation...
--
Ehsan
<http://ehsanakhgari.org/>