Hey there, thanks for the PR. I like this idea overall. Out of curiosity do you have any additional context or examples of where this helps in the wild?

I went through handle_selection_request to look at what errors it deals with and everything seems to come from the X11 connection's fallibility. Looking at the error types and upstream documentation, it seems like most of the enum variants are fatal? I'm not an X11 expert but my reading is that anything prefixed with XCB_CONN_ means future requests won't work again because the server has closed our socket. Does that match up with your understanding?

Given that, these seem like the only errors we are able to ignore during operations:

• UnknownError
• IoError

Should we have some kind of way to programmatically get the error, rather than logging it?

As much as I would like that the current architecture of the X11 clipboard doesn't support that. The background thread isn't owned by any specific Clipboard instance, so without a lot more global state (and bookkeeping) I don't see how we can cleanly pass an error from a specific .set() call.

Out of curiosity do you have any additional context or examples of where this helps in the wild?

I have an image organizer app, and it allows copying images to the clipboard.
However, if a very large image gets copied, it gets a Maximum request length exceeded error, which kills the worker thread.

With this patch, it won't kill the worker thread, so the user can keep copying other images (and strings, etc.).

it seems like most of the enum variants are fatal? I'm not an X11 expert but my reading is that anything prefixed with XCB_CONN_ means future requests won't work again because the server has closed our socket. Does that match up with your understanding?

Well, x11rb is its own thing, not bindings to XCB, so I wouldn't take the XCB documentation as "upstream".

However, if a very large image gets copied, it gets a Maximum request length exceeded error, which kills the worker thread.

With this patch, it won't kill the worker thread, so the user can keep copying other images (and strings, etc.).

Thanks, that's helpful to know!

Well, x11rb is its own thing, not bindings to XCB, so I wouldn't take the XCB documentation as "upstream".

That's a very valid point. It was unclear how much of the error handling x11rb inherited from XCB but given that you've tested this patch doesn't result in a dead connection (which would have been XCB_CONN_CLOSED_REQ_LEN_EXCEED if this was XCB), I'm inclined to agree. Given that I had no other feedback, I think this is good to go.

do you mind confirming that you did actually test that future copy operations work after the length exceeded error is logged?

Yes, I tested it, and can confirm future copies work

If there is a way to check that the connection is closed, we could add a check for that in the event loop, and terminate if the connection is closed.
I'll investigate when I get home.

Hey again, did you manage to find anything here? I skimmed through x11rb's documentation but didn't spot anything. I'm hoping to cut an arboard release this week with the bug fix backlog.

I'm thinking this might be low-risk to merge and see. I can always make a patch release if this causes unexpected problems.

Sorry, I didn't manage to find anything, and kind of forgot about this.
If you think it's good to merge, go ahead! Thank you!

This behavior change is now present in 3.6.0 of arboard on crates.io.