When an xclip-owned selection has enough data to trigger the use of the INCR protocol when transferring, and an application that doesn't implement the INCR protocol requests clipboard data, xclip will enter the XCLIB_XCIN_INCR state, and then wait forever for the application to delete the INCR property, which will never happen.
While in that state, SelectionRequest events from other applications are not processed, and so the clipboard data becomes inaccessible: any application that tries to access the selection will freeze, waiting forever for a SelectionNotify event from xclip.
In my case, this bug was triggered by fcitx automatically grabbing the contents of the clipboard and locking up xclip whenever I tried to xclip -i something larger than 1MB, like a big enough screenshot. Killing fcitx let the clipboard work as expected, but I don't think a misbehaving application should be allowed to lock up xclip in the first place.
I'm not sure what the best solution would be for this ; I have an ugly fix here which "solves" the problem by just not caring about state at all and always responding to SelectionNotify events. That works well enough for me, but it is still pretty fragile (what happens if two applications request data at the same time?)...
Ideally, xclip should keep track of every INCR transfer separately so that it can still serve clipboard data while it's waiting for another INCR transfer to complete, but i'm not familiar enough with the code to actually implement that.
When an xclip-owned selection has enough data to trigger the use of the INCR protocol when transferring, and an application that doesn't implement the INCR protocol requests clipboard data, xclip will enter the XCLIB_XCIN_INCR state, and then wait forever for the application to delete the INCR property, which will never happen.
While in that state, SelectionRequest events from other applications are not processed, and so the clipboard data becomes inaccessible: any application that tries to access the selection will freeze, waiting forever for a SelectionNotify event from xclip.
In my case, this bug was triggered by fcitx automatically grabbing the contents of the clipboard and locking up xclip whenever I tried to xclip -i something larger than 1MB, like a big enough screenshot. Killing fcitx let the clipboard work as expected, but I don't think a misbehaving application should be allowed to lock up xclip in the first place.
I'm not sure what the best solution would be for this ; I have an ugly fix here which "solves" the problem by just not caring about state at all and always responding to SelectionNotify events. That works well enough for me, but it is still pretty fragile (what happens if two applications request data at the same time?)...
Ideally, xclip should keep track of every INCR transfer separately so that it can still serve clipboard data while it's waiting for another INCR transfer to complete, but i'm not familiar enough with the code to actually implement that.