28372 nightly build - commit message editing area is readonly sometimes

[Vasily Galkin]

Hello.
TortoiseSVN is a great software, thanks for it!


I understand that reporting bugs is sometimes unnecessarily, but current nightly build has a "floating" bug, that often reproduces on my machine (and I'm not sure that it would be found by "author testing" since it is floating).

Prepare:
0. Copy any text in clipboard.

Steps to reproduce:


1. Right-click any repo file in explorer, Select SVN Commit...
-commit window apppears, cursor is blinking.
2. Right-click commit message area
-menu appears

Actual result:
-in ~70% cases "Paste" is grayed and unavailable (keyboard input doesn't work too, but I'm using virtual keyboard (synergy) so it's not a good thing to test for me). However, recent message can be selected with button - and then it appears in the text area.
-in ~30% cases "Paste" is available and keyboard input DO work fine.

Expected result:
-in 100% cases "Paste" is available and keyboard input DO work fine.


Problem reproduces completely random (tried several times in a row using keyboard only with exactly same keyboard pressess teps and sometimes it works sometimes not).

The problematic nightly build is
TortoiseSVN 1.10.99, Build 28372 - 64 Bit -dev, 2018/09/16 12:39:18
on mostly up-to-date windows 7 x64.

Previously I was using several-months before nightly build and there wasn't such problem (or extremely rare).

[Luc Van der Veken]

This sounds familiar. You're not running that inside a virtual machine, or in an RDP session, by any chance?

I'm not even sure if it's in RDP sessions or in VMWare virtual machines that I sometimes experience it, or both, but I *do* have noticed that the clipboard can be emptied unexpectedly.

Copy the same text to the clipboard again, even without re-opening the target window you want to paste into, and it (usually) works.

I think it happens -- sometimes -- when the focus is moved from one machine to the other and back.

I often have a VM or an RDP session (or both) running on one monitor with the other still used locally. Moving the mouse from one screen to the other and back, without even clicking, can be enough.

Having non-text data (an image for example) on the local clipboard seems to make it worse, even to the extent that I sometimes have to clear the local clipboard (by copying an empty string) before I can copy text on the other one again.

[Vasily Galkin]

I tried with completely closing rdp sessions and disabling the software that teoretically can "mess" with keyboard and clipboard (synergy), and TortoiseSVN behaviour doesn't change.

And the clipboard is not empty - on one of the next TortoiseSVN executions, when the problem doesn't appear - pasting works fine.

It doesn't look like clipboard problem, it looks more like problem with some "readonly" state of log message input area.

[Stefan]

On Friday, September 21, 2018 at 11:10:02 AM UTC+2, Vasily Galkin wrote:

I tried with completely closing rdp sessions and disabling the software that teoretically can "mess" with keyboard and clipboard (synergy), and TortoiseSVN behaviour doesn't change.

And the clipboard is not empty - on one of the next TortoiseSVN executions, when the problem doesn't appear - pasting works fine.

The clipboard is a global resource. If another app opens the clipboard but forgets to close it, other apps can not use it.

https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-openclipboard

https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-closeclipboard

I've had the same problem once, but only until I found the tool that misbehaved and I removed it.

Some tools just call OpenClipboard but fail for whatever reason to call CloseClipboard. The reason it works for you sometimes is that Windows automatically closes the clipboard again if the process that opened it exits.

you could try a tool like Clipboard Spy or ClipSpy+ (https://www.codeproject.com/Articles/22624/ClipSpy).

Stefan

[Vasily Galkin]

Just reporting that the issue IS FIXED in TortoiseSVN 1.11.0 Release.

After updating to it the "uneditable commit message" problem disappeared.

Thanks.

пятница, 21 сентября 2018 г., 16:56:30 UTC+3 пользователь Stefan написал: