Tk Source Code

You are right, merging to 8.6 was premature. So, put back to "bug-ee397e0a55" branch.

Jan I don't understand your always rushing in merging work in progress in branches I had opened. That's very disturbing to me. While I appreciate your testing, I didn't ask for more at this stage.

I don't consider the work to be done for the present ticket. Documentation for the new function OpenClipboardRetry() is missing, moreover you promoted it to a TkWinOpenClipboardRetry() because you wanted to use it in another file than win/tkWinClipboard.c, which I'm not sure it's needed there. Further, proper handling the return value TCL_ERROR from that function is missing in now two places. This is just half-made job in my view. Now since you took it from my plate, be my guest and make whatever further step you want including none.

Regarding your specific question: For ages these tests did pass by accident when TightVNC or applications alike are open. In such cases, OpenClipboard() fails and before commit [0e71aba7ff68641f] this case was leading to the same error as what is expected in the test cases. So the tests did pass, but for the wrong reason. Commit [0e71aba7ff68641f] introduced a difference in the error message to distinguish cases when OpenClipbopard() fail. As a consequence, applications such as WSL or TightVNC which really seem to lock the clipboard will make some clipboard tests fail for this reason. I don't see a way to fix this, except reverting [0e71aba7ff68641f].

Fixed [ffb5d8f227b3a405|here]

Confirming that the fix indeed works in my environment.

OK to close? Or do you want to continue investigating this for WSL/TightVNC?

With [4f8ad61c] I believe the issue reported by Jan is gone. At least I can no longer make clipboard.test tests fail when VirtualBox is running.

Explanation why the tests started to return 0 instead of 1 (the expected error code) after [ed6b6462]: with this commit, TkSelGetSelection() does no longer fail at first attempt when trying to OpenClipboard(). Retries allow to wait a bit and the clipboard is properly opened in the [clipboard get] command. After [ed6b6462] the tests started to no longer return the expected error because UpdateClipboard() didn't check the error code returned by OpenClipboard(). Then EmptyClipboard() did nothing since the clipboard was not open, and the clipboard ownership was not transferred as expected. The clipboard was not cleared and [clipboard get] returned the previoçus content "i.e. 'Test'). [4f8ad61c] now retries in UpdateClipboard(). I believe we had a race condition with ourselves in the sequence

clipboard append "Test"
selection clear -s CLIPBOARD
clipboard get

(Adding "after 10" before [selection clear ...] let the tests pass without [4f8ad61c])

Failures when using WSL or TightVNC still remain, because here even 7 retries are not enough.

Having installed VirtualBox with an Ubuntu 22.04 guest, I can now also reproduce what Jan is seeing.

I understand your doubts Ashok. I have installed WSL for the sake or reproducing the issue and I'm now seeing the same as you do. Reboot and the tests pass. Now execute "wsl" and the tests fail (7 failed retries).

What Jan sees is different (only one retry, and the tests end with 0 return code instead of the expected error, which I can't explain so far). I'll install VirtualBox to make sure his situation is reproducible also.

Also, I am not convinced that failures are due to another application having clipboard always open. If that was the case, wouldn't we see failures in other applications when doing "normal" day to day work?

Sorry about the very late response, completely slipped my mind to try this.

Anyway results below:

```
clipboard.test
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 1
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 2
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 3
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 4
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 5
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 6
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 7


==== clipboard-4.1 ClipboardLostSel procedure FAILED
==== Contents of test case:

    clipboard append "Test"
    selection clear -s CLIPBOARD
    clipboard get

---- Result was:
clipboard cannot be opened, another application grabbed it
---- Result should have been (exact matching):
CLIPBOARD selection doesn't exist or form "STRING" not defined
==== clipboard-4.1 FAILED

>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 1
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 2
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 3
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 4
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 5
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 6
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 7


==== clipboard-4.2 ClipboardLostSel procedure FAILED
==== Contents of test case:

    clipboard append "Test"
    clipboard append -t TEST "Test2"
    selection clear -s CLIPBOARD
    clipboard get

---- Result was:
clipboard cannot be opened, another application grabbed it
---- Result should have been (exact matching):
CLIPBOARD selection doesn't exist or form "STRING" not defined
==== clipboard-4.2 FAILED

>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 1
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 2
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 3
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 4
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 5
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 6
>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 7


==== clipboard-4.4 ClipboardLostSel procedure FAILED
==== Contents of test case:

    clipboard append "Test"
    clipboard append -t TEST "Test2"
    clipboard append "Test3"
    selection clear -s CLIPBOARD
    clipboard get

---- Result was:
clipboard cannot be opened, another application grabbed it
---- Result should have been (exact matching):
CLIPBOARD selection doesn't exist or form "STRING" not defined
==== clipboard-4.4 FAILED
```

Well, I tried the patch. Before:

clipboard.test
==== clipboard-4.1 ClipboardLostSel procedure FAILED
==== Contents of test case:

clipboard append "Test"
    selection clear -s CLIPBOARD
    clipboard get


---- Result was:
clipboard cannot be opened, another application grabbed it
---- Result should have been (exact matching):
CLIPBOARD selection doesn't exist or form "STRING" not defined
==== clipboard-4.1 FAILED

==== clipboard-4.2 ClipboardLostSel procedure FAILED
==== Contents of test case:

clipboard append "Test"
    clipboard append -t TEST "Test2"
    selection clear -s CLIPBOARD
    clipboard get


---- Result was:
clipboard cannot be opened, another application grabbed it
---- Result should have been (exact matching):
CLIPBOARD selection doesn't exist or form "STRING" not defined
==== clipboard-4.2 FAILED

==== clipboard-4.4 ClipboardLostSel procedure FAILED
==== Contents of test case:

clipboard append "Test"
    clipboard append -t TEST "Test2"
    clipboard append "Test3"
    selection clear -s CLIPBOARD
    clipboard get


---- Result was:
clipboard cannot be opened, another application grabbed it
---- Result should have been (exact matching):
CLIPBOARD selection doesn't exist or form "STRING" not defined
==== clipboard-4.4 FAILED
...

After:

clipboard.test
==== clipboard-4.1 ClipboardLostSel procedure FAILED
==== Contents of test case:

clipboard append "Test"
    selection clear -s CLIPBOARD
    clipboard get


---- Test completed normally; Return code was: 0
---- Return code should have been one of: 1
==== clipboard-4.1 FAILED

>>>>>>>>>>>>>>>>>>>>> OpenClipboard RETRY, attempt 1

==== clipboard-4.2 ClipboardLostSel procedure FAILED
==== Contents of test case:

clipboard append "Test"
    clipboard append -t TEST "Test2"
    selection clear -s CLIPBOARD
    clipboard get


---- Test completed normally; Return code was: 0
---- Return code should have been one of: 1
==== clipboard-4.2 FAILED

==== clipboard-4.4 ClipboardLostSel procedure FAILED
==== Contents of test case:

clipboard append "Test"
    clipboard append -t TEST "Test2"
    clipboard append "Test3"
    selection clear -s CLIPBOARD
    clipboard get


---- Test completed normally; Return code was: 0
---- Return code should have been one of: 1
==== clipboard-4.4 FAILED
...

So, it looks like an improvement, but we aren't there yet ....

Thinking at this again, the problem may not be a race condition but an application that looks in the clipboard at unexpected times. This would give the impression of a race condition because sometimes the tests pass, and sometimes they don't.

There are some reports on the internet about this problem in applications other than Tk, see for instance this newsgroup thread. Developers mention that some applications may open the clipboard without the user being aware of this, which makes OpenClipboard() fail. They introduced a retry process when OpenClipboard() fails, see this commit.

I have adapted their fix to Tk [ed6b6462|here]. Of course this does not work when facing applications that keep the clipboard open all the time (such as TightVNC), but it should work when facing other applications that shortly open the clipboard.

Ashok, Jan, what do you think? Could you perhaps try in your environment? I have left the printf debug line in place on purpose. If you see one or two "RETRY" lines in your clipboard.test output then it means you probably have an application that grabs the clipbopard for short amount of times only ; if you see 7 "RETRY" lines, then you probably have an application that has the clipboard always open. Thanks!

Hmmm... When, while a VNC connection is active, I paste the following (contents of clipboard-4.1) at once on Windows in a tclsh:

    clipboard clear
    clipboard append "Test"
    selection clear -s CLIPBOARD
    clipboard get

I do not get the same result all the time. Sometimes it's:

    clipboard cannot be opened, another application grabbed it

    CLIPBOARD selection doesn't exist or form "STRING" not defined

This probably means there is a race condition somewhere.

Testing the [clipboard] command interactively is a pain, because everything must be typed (not copy/pasted), of course!

Well, I do run WSL/Hyper-V though I tested without any WSL terminals open but may be there is something running in the background.

But that would not explain why I see the expected behavior if I try out the sequence of commands in the test from a wish console. That hints at some kind of timing issue or some remnants within the test suite that causes the failure.

If I try running the tests individually (-match) in a batch loop, 4.1 and 4.2 pass sometimes and fail at other times. 4.4 passed consistently (10 iterations)

I'm on Windows 10, not sure if Jan is also on Win 10.

I'm seeing the same problem. I don't have VNC, but my suspicious application is VirtualBox (because it uses a shared clipboard)

Puzzled. I'm not seeing this on my Windows 11, nor at GitHub for the Windows job (running on Windows Server 2022).

I just checked this with latest core-8-6-branch and core-8-branch. I'm afraid there is no change.

As far as I know there is no VNC or clipboard "manager" running but with all the junk that runs in the background on Windows these days, who knows.

If I try running the commands by hand in a wish console, 4.1 and 4.2 return the expected error message. 4.4 does not raise and error but returns successfully with result "TestTest3" (no Test2 intervening).

/Ashok

Ashok, can you still reproduce (after checking there is no VNC connection to another machine, see below)? If not, let's close this.

I'm definitely seeing this each time I have a VNC connection to another machine while running Tk tests on the local platform.

Apart from this, no idea, except the error message showed up in previous reports.