[Bug: 21.4.12] xemacs: X Error of failed request:BadWindow(invalid Window parameter)

[Glynn Clements]

tbennett at nvidia.com wrote:

> >> > A clipboard helper would be an obvious candidate, as it will 
> >> > request the selection/clipboard contents as soon as it sees 
> >> > any change (whereas manually pasting would typically involve 
> >> > some delay).
> >> 
> >> This sounds like it could well the be cause of the problem,
> >> and turning it off or reconfiguring it could make the problem
> >> go away but it's not solving the problem.
> >
> > My guess (and it's only that) is that x_reply_selection_request() is
> > calling wait_for_property_change() with the intention of resuming the
> > transfer afterwards, but wait_for_property_change() ends up
> > dispatching the event to a recursive invocation of
> > x_handle_selection_request() which tries to transfer the selection
> > from scratch (with the fact that the transfer is actually underway
> > being recorded only in local variables within outer invocations).
> >
> > BTW, one other thing has occured to me: if the local event loop
> > consumes process output, the selection may be growing faster than it
> > can be transferred.
> 
> Does any of XEmacs or window manager(?) or clipboard utility have
> behavior that changes based on the size of the selection?  This
> particular problem only happens for me with large (3 to 5Meg)
> selections.

If the selection is too large to be transferred in a single chunk, an
incremental selection is used, and it's incremental selections which
are causing the problem.

You can determine the limit from the "maximum request size" value in
the output from "xdpyinfo".

-- 
Glynn Clements <glynn at gclements.plus.com>