hackerb9
commented
3 years ago Certain programs send many more paste requests than they should. For example, middle-click pasting into this very message using Mozilla Firefox triggered 21 paste requests, the first sixteen of which are simply duplicate requests for TARGETS (the list of available targets). Since requests for special targets like TARGETS, TIMESTAMP, and MULTIPLE aren't genuine pastes, they should not increment dloops. This should be fairly easy for us to fix.
However, that still leaves five paste requests for that single middle click. The browser asks for five different targets: text/plain;charset=utf-8, UTF8_STRING, COMPOUND_TEXT, STRING, and text/x-moz-text-internal. Since xclip only holds one format, xclip should decline the other four of those requests and not increment dloops. (This is bug #94).
Once those two problems are solved, we should reevaluate whether the loops feature is still broken.
- Once xclip has started sending the data, should it count as a "loop" even if the client reports an error? Generally, it seems like the answer should be "No", but then I don't actually understand the use case for -loops. Is security its purpose? If the
-sensitiveflag (#70, #85) will rely on dloops to function, the answer should be "Yes". - Do any applications presume they can request the clipboard a second time instead of caching the data?
- Is loops even a useful concept once xclip can handle more than one target (bugs #32, #101)?
- How are loops counted if we can handle
MULTIPLErequests in a batch (bug #93)? Does each step count as a loop or do we only increment dloops once? What if some of the steps fail?
[Side note: I do not understand why the browser sends sixteen requests for TARGETS; my guess is that there are sixteen specific formats it is looking for and the programmers who wrote the comparison didn't know to cache the results the first time. Likewise, I do not understand why, after receiving sixteen copies of the list of supported formats, Firefox then ignores that list and asks for formats we did not advertise. Is this a bug we should open with Mozilla or are we doing something wrong?]
The '-loops' feature suggests that you can control how many times the selection can be pasted, but depending on what window you're pasting into, it needs multiple iterations of the loop. In other words, some windows need '-loops 2' or even '-loops 3' to paste the selection one time.
I submitted pull https://github.com/astrand/xclip/pull/72 that 'dloop' should be incremented only on the non-target version of XChangeProperty() (the one using 8-bits) thinking that the whole selection was fully pasted into the window on that call. However I found on some OS and window configurations that didn't hold true. Using Debian 9 and FireFox for example, trying to paste a selection into the address bar requires several calls to the XChangeProperty via targets, and two calls to XChangeProperty with non-target 8-bit version of the call. Therefore if '-loops' was set to '1' it would not get pasted into the address bar.
I'm not sure if I'm just misunderstanding the purpose of the '-loops' feature or if it's just not working correctly, but if it is supposed to limit the amount of times the selection can be pasted, it needs to be able to more accurately count when a selection has actually been pasted despite the discrepancies in how many times xcin() and its associated XChangeProperty() calls are entered.
I'm wondering if there is a way to examine the window property and compare it with what is in the selection buffer in xclip, and only increment 'dloop' once they're both equal?