Copy-paste of selections with Xlib in X11: XA_TARGETS array of atoms

Question

I've implemented copy-paste of text strings in an Xlib program. When my program owns the current selection, and I paste into xterm, or into a text field in gimp, or into firefox, it works fine: the program I'm pasting into sends a SelectionRequest event to my program with target XA_UTF8_STRING ("UTF8_STRING"), and my program responds appropriately and the string is pasted.

However, when my program owns the current selection, and I try to paste into a message composition window in Thunderbird (version 16.0.2) or text field in the SeaMonkey web browser (version 2.20), Thunderbird and SeaMonkey send a SelectionRequest event to my program with target XA_TARGETS ("TARGETS"), and something goes wrong. My understanding is that my program is supposed to respond with an array of the targets that it can provide - the relevant code of my program is below. (Note that this is on a 64 bit machine, and the Atom type is 64 bits). Thunderbird / SeaMonkey don't seem happy with my response, because they then send my program many subsequent SelectionRequest events, with different targets, as if they are trying to see which one I will return (they try application/x-moz-nativehtml, text/html, application/x-moz-file, image/png, image/jpeg, image/gif) and then finally try the target UTF8_STRING, to which my code responds successfully and the string is pasted. This can all take 1 second or more, so there is a noticeable delay before the string is pasted.

To try to debug things, I modified my code so that when I paste into my program, and another program is the owner, I send them a SelectionRequest event with target XA_TARGETS, so I could see how Thunderbird or SeaMonkey respond. I get back a SelectionNotify event, with target XA_TARGETS, and the event's property set to the one I requested, and when I read that property on my own window, I find it is an array of type XA_ATOM, format 32, and length 0. So I don't seem to get any array of targets from Thunderbird or SeaMonkey when I ask them for it.

Platform: Ubuntu 12.10 Linux x86_64

A reference I used: http://svn.gna.org/svn/warzone/trunk/lib/betawidget/src/platform/sdl/clipboardX11.c

...
if ( event.type == SelectionRequest ) {
  Atom propertyOfRequestorToSet = event.xselectionrequest.property==None ? XA_PRIMARY : event.xselectionrequest.property;

  XSelectionEvent selEvent;
  selEvent.type = SelectionNotify;
  // selEvent.serial = event.xselectionrequest.serial; // I don't know if this is correct
  selEvent.send_event = True;
  selEvent.display = my_display;
  selEvent.requestor = event.xselectionrequest.requestor;
  selEvent.selection = event.xselectionrequest.selection;
  selEvent.target = event.xselectionrequest.target;
  selEvent.property = None;
  selEvent.time = event.xselectionrequest.time;

  if ( event.xselectionrequest.target == XA_TARGETS ) {

    Atom possibleTargets[] = { XA_UTF8_STRING, XA_STRING, XA_TEXT }; // [Note 2]

    // I checked, and this call returns 1
    XChangeProperty( my_display, event.xselectionrequest.requestor,
      propertyOfRequestorToSet,
      XA_ATOM,
      32, // 32 bits actually means long, according to what I've read // [Note 1]
      PropModeReplace,
      (unsigned char *) possibleTargets,
      sizeof(possibleTargets)/sizeof(possibleTargets[0])  // [Note 3]
    );

    selEvent.property = propertyOfRequestorToSet;
  }
  else ... {
  }

  if ( 0 == XSendEvent( my_display, selEvent.requestor, False, 0L, (XEvent*)&selEvent ) ) {
    printf("call to XSendEvent() failed\n");
  }
}

Note 1: if I pass 64, I get a BadValue X Error.

Note 2: I've tried replacing this line with int possibleTargets[] = { (int)XA_STRING, (int)XA_UTF8_STRING, (int)XA_TEXT }; so that the array would be of 32-bit words, and the behavior is the same.

Note 3: I've tried passing an array of 1 or even 0 elements, and the behavior is the same.

In the call to XChangeProperty(), I also tried passing a format of 8 and length of sizeof(possibleTargets), as in the answer at ( Clipboard selection transfer does not work ) but I still observe the same behavior.