Copying data to clipboard in xpcshell tests

[Ehsan Akhgari]

In the process of writing a test for bug 462106, I'm trying to get the
following function to work in the xpcshell environment:

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/>

[Justin Dolske]

On 1/23/09 7:35 AM, Ehsan Akhgari wrote:

> 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

[Ehsan Akhgari]

On Sat, Jan 24, 2009 at 1:09 AM, Justin Dolske <dol...@mozilla.com> wrote:
> On 1/23/09 7:35 AM, Ehsan Akhgari wrote:
>
>> 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.

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/>

[Neil]

Ehsan Akhgari wrote:

>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.

[Ehsan Akhgari]

On Mon, Jan 26, 2009 at 2:51 PM, Neil <ne...@parkwaycc.co.uk> wrote:
> Ehsan Akhgari wrote:
>
>> 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.

Yes, that seems like a logical explanation...

--
Ehsan
<http://ehsanakhgari.org/>