Copyq: [Xorg] regression in 3.3.1 with primary selection

[blueyed]

With CopyQ 3.3.1 you cannot paste the primary selection from a window that has been closed anymore, but have to first select it from the main window.

TEST CASE:

1. open a terminal window
2. select text using the mouse
3. pasting using the middle mouse button works now
4. close the terminal window
5. pasting using the middle mouse button does not work

Relevant settings from "Clipboard Manipulation":

1. Store clipboard
2. Store text selected using mouse
   Others are not enabled.

This works with 3.3.0. Please let me know if I should bisect it.
Using Arch Linux.

[blueyed]

Workaround:

1. open the main window with the list of stored items.
2. press Enter to re-select the last one
3. now you can paste it using both middle-mouse (as a selection), and Ctrl-v (as clipboard).

[hluk]

Sorry, I removed this functionality (5e1a8c930824740628eabfc95a5af161bbce0381) since the clipboard is usually cleared by password managers and I had some other issues with the old code.

I think it can be re-added using script commands. I'll try to create the command and perhaps add it the predefined commands in Command dialog.

[blueyed]

since the clipboard is usually cleared by password managers

This worked for me as expected (using pass), but it uses the clipboard and not the selection (IIRC).
From the description of https://github.com/hluk/CopyQ/commit/5e1a8c930824740628eabfc95a5af161bbce0381 and your comment it sounds like something different though, and maybe this regression is just an unwanted side effect of this?

For me one of the main reasons for using a clipboard manager is to have the selection still available when closing the owning window - without having to explicitly re-select it.

[blueyed]

Any update on this, e.g. a script command that would do it?

(I was about to file the same issue again (forgetting that I've done it already), and noticed that it appears to also be the case when using the "Paste mouse selection with keyboard" setting in the Clipboard Manipulation settings - which confused me a bit, since I would have expected this option would store the selection somehow already.)

[blueyed]

Also I cannot see how "X11: Omit resetting empty clipboard and selection" (5e1a8c9) applies here really.

[hluk]

Some clarification: If you close the application "owning" clipboard/selection (the app where you copied something last time) on X11 the copied data will be lost because it's the X11 app that need to provide it when requested by other apps.

Commit 5e1a8c9 removes this functionality because there were few problems:

• It was not configurable and interfered with tests.
• The code was specific to X11 and not available on other platforms.
• Password managers clear copied password/username after interval (though, as you mentioned, the manager may not work with X11 selection).
• After some code refactoring this code didn't work well - so I had to either fix it, which was not trivial, or remove it.

Anyway, you can re-add the functionality with following command.

[Command]
Command="
    var timeoutMilliseconds = 100;

    var clipboardId = 0
    var selectionId = 0
    var lastSelection = ''
    var lastClipboard = ''

    function resetClipboard(id) {
      var id = ++clipboardId

      if (hasData()) {
        lastClipboard = data(mimeText)
      } else {
        afterMilliseconds(timeoutMilliseconds, function() {
          if (id == clipboardId)
            copy(lastClipboard)
        })
      }
    }

    function resetSelection(id) {
      var id = ++selectionId

      if (hasData()) {
        lastSelection = data(mimeText)
      } else {
        afterMilliseconds(timeoutMilliseconds, function() {
          if (id == selectionId)
            copySelection(lastSelection)
        })
      }
    }

    var onClipboardChanged_ = onClipboardChanged
    onClipboardChanged = function() {
      isClipboard() ? resetClipboard() : resetSelection()
      onClipboardChanged_()
    }"
Icon=\xf246
IsScript=true
Name=Reset Empty Clipboard/Selection

I hope that command works for you, I really don't want to implement this in the app's code.

I can add the command to copyq-commands repo if it works fine.

[blueyed]

@hluk
Finally came back to this - the script fixes the issue for me, thanks!
It does not appear to be a problem with the clipboard though, i.e. resetClipboard is not needed it seems - only the X11 selection is affected here.

[blueyed]

@hluk

1. Can you comment on the part with resetClipboard?
2. Do you still plan to add it to copyq-commands?
3. Can the timeoutMilliseconds be shorter? I think I often close e.g. a terminal window too fast for this script to handle it properly (and I just assume that it's because it happens too fast, but there are certainly other events (onClipboardChanged) involved first anyway). Why is the timer needed internally after all? (if so)

[hluk]

@blueyed

Can you comment on the part with resetClipboard?

I tried to make the command work as it was implemented before in CopyQ.

Do you still plan to add it to copyq-commands?

Sure.

Can the timeoutMilliseconds be shorter?

I try not to change clipboard too fast - it could break some apps. But maybe, in this case, the interval can be removed since there is already a small interval before new clipboard content is handled.

Did you try to remove the interval? Can create PR for the command if it works for you?

[blueyed]

Thanks, will give it a try for a while and report back / create a PR.

[scottkosty]

I guess the ideal behavior is to not use the command and to instead configure the individual applications if possible? For example, Vim apparently resets the clipboard, although I don't understand why. This answer suggests adding an entry to .vimrc and that indeed solves the issue for me: https://stackoverflow.com/a/9381778/1376404
That Vim-specific workaround doesn't work for gVim, though.

I did test the CopyQ command. It does seem to work. Thanks for adding that @hluk ! The command (expectedly) leads to more snip animations. For example, I get snip animations when I exit an application that did not have the issue (i.e,. I don't think it resets the clipboard). I am happy though, since I know the command is a workaround so I understand it might come with consequences. Thank you!

[blueyed]

For what it's worth I am using the following currently:

var selectionId = 0
var lastSelection = ''
var lastSelectionMime = ''

function resetSelection(id) {
  var id = ++selectionId

  // notification(
  //   '.id', 'resetSelection',
  //   '.title', 'resetSelection',
  //   '.message', 'id: ' + id + ', hasData(): ' + hasData() + ', data: ' + str(data(mimeText))
  // )

  if (hasData()) {
    lastSelection = data(mimeText)
  } else {
    // notification('.message', id + ': set: ' + str(lastSelection))
    setData(mimeText, lastSelection)
    provideSelection()
  }
}

var onClipboardChanged_ = onClipboardChanged
onClipboardChanged = function() {
  if (!isClipboard()) {
    resetSelection()
  }
  onClipboardChanged_()
}

Also note that I am not syncing clipboard/selection via settings.

[scottkosty]

@blueyed thanks! I'll try first to stick with the built-in command, but if I would like to change the behavior, I will study your command.

[scottkosty]

The built-in command works 95% well for me. The only problem I've seen is that when I am in a specific application (LyX), in some cases a selection I make is broken. e.g., I select something, and immediately after it is deselected without me doing anything.

[blueyed]

I select something, and immediately after it is deselected without me doing anything.

Do you use the "Paste clipboard with mouse" and/or "Paste mouse selection with keyboard" options? Those might cause this, when CopyQ synchronizes the clipboard (and takes ownership). This also removes the (visible) selection in urxvt for me.
You can use the example script at the bottom of https://copyq.readthedocs.io/en/latest/commands-script.html?highlight=notification to see what is going on.

[scottkosty]

Do you use the "Paste clipboard with mouse"

I do use this one.

You can use the example script at the bottom of https://copyq.readthedocs.io/en/latest/commands-script.html?highlight=notification to see what is going on.

Good to know! That looks very helpful for debugging.

[blueyed]

@hluk
I've just gone back to your original version (https://github.com/hluk/CopyQ/issues/925#issuecomment-406982485) for debugging purposes and noticed that selectionId and clipboardId are not persistent across script runs? (i.e. they start at 0 always)
Isn't the script expected to be persistent?

Also the timer (afterMilliseconds) does not seem to be run?!
I've added notifications before and after afterMilliseconds, which get called, but not the one in the callback?!

CopyQ Clipboard Manager v3.7.2
Qt: 5.12.0
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: Arch Linux

[hluk]

Oh, onClipboardChanged() is no longer called from clipboard monitor process, but from a new process whenever clipboard changes, so the state of variables like selectionId won't persist.

Following command solves it by storing the last clipboard/selection texts using settings instead. Also the sleep(...) is needed to ensure the callback registered with afterMilliseconds() is called before the process exits.

[Command]
Command="
    var timeoutMilliseconds = 100;

    function reset(key, copyFn) {
      if (hasData()) {
        settings(key, [data(mimeText), Date.now()])
      } else {
        last = settings(key)
        afterMilliseconds(timeoutMilliseconds, function() {
          if (last[1] == settings(key)[1])
            copyFn(last[0])
        })
      }
    }

    function resetClipboard() {
      reset('lastClipboard', copy)
    }

    function resetSelection() {
      reset('lastSelection', copySelection)
    }

    var onClipboardChanged_ = onClipboardChanged
    onClipboardChanged = function() {
      isClipboard() ? resetClipboard() : resetSelection()
      onClipboardChanged_()
      sleep(timeoutMilliseconds)
    }"
Icon=\xf246
IsScript=true
Name=Reset Empty Clipboard/Selection

[blueyed]

Thanks. Just for reference, this was changed in aebeb02007aa1ef86f61b252d6b4991e3ec4325b.

[scottkosty]

Thanks to both of you for continuing to update the script. It stopped working for me and I gave up on it but I'm glad I'll have something to try next time I take a look at this.

[hluk]

I should resume work on automated tests in copyq-commands repository. Those would help avoid such issues in future.