virtualbox.org

michael wrote:So again, this happens when the Additions are not installed too, and is triggered by a click inside of an application window, but not by a click outside of one? Regarding Enterprise Linux 7.6, yes, support was only added with 5.2.23.

Yes, I could confirm that it happens when the Guest Additions are not installed, too. And it only seems to be triggered by a click inside of an application window, but not by a click outside of one. And I could confirm, that this did not happen with RHEL 7.5.

michael wrote:Is this always on Windows hosts?

No. It happens on a Ubuntu 18.04 LTS host system, too.

I'm running the test build version 5.2.23 r126798 (Qt5.6.1). As I use RHEL as VirtualBox guest on a regular basis I would like to help solving this issue. But I would need instructions on how to do so.

Edit: I've opened a thread in the Red Hat community. You could find it at: https://access.redhat.com/discussions/3714911

Maybe some users over there could give additional insight on this.

Regards,
JoergK

I'm running on a Windows 10 Build 16299. Confirming the issue happens with and without Guest Additions installed (noting Guest Additions 5.2.23 was required in order to compile for 7.6)
I redeployed the 7.6 VM using VMWare Workstation Player 15 and the problem does not exist.

In terms of clicking - it appears to have trouble shifting focus. The focus could be an application window or the application launcher or the panel. Doesn't really seem to matter which.

Yay I'm not crazy! Boo...this sucks

OOC has anyone tried with the VirtualBox 6 beta?

Hello,

same here: CentOS 7.6 running in the host on top of Fedora 26 or 28, tried with VirtualBox 5.2.22 as well as 6.0.0-beta3 and latest builds of 6.0.0-beta3, with guest-additions installed.
Upon the first click inside a KDE desktop (to start a terminal from the "panel"), left-clicks are not working anymore (I cannot use the panel, move windows or even select text inside the terminal; xev does not seem to receive events either).
Interestingly, shutting down the session (luckily right-click was still working) and starting again seems to resolve the problem (ie. after the session was restarted, the problem seems to be gone, until the next restart of the virtual machine).

Another point I spotted: I tried running "xwininfo -tree" to debug somewhat more, and it kept bailing out with
xwininfo: error can't grab the mouse

It would not explain this happening without the Additions running, but does stopping all VBoxClient processes running in the guest make a difference? If not then I have a guess as to what is happening: there is an age-old bug in X.Org which for timing reasons might happen more often in virtual machines than on physical hardware. What happens is that for some reason, a mouse button grab is not released when it should be, and persists until the window which grabbed the button is destroyed. At one point with one random Ubuntu release this was affecting VirtualBox on the host system quite often, as we need to grab the mouse button. I have also occasionally seen it on my host system in Ubuntu Unity without VirtualBox running at all. Sadly no one has ever tracked down the bug, and the one time I tried to work through the X.Org grabbing code I gave up after a couple of hours of frustration.

slevey wrote: In terms of clicking - it appears to have trouble shifting focus. The focus could be an application window or the application launcher or the panel. Doesn't really seem to matter which.

I'm running CentOS 7.6 as a guest (with 5.2.23 guest additions) on top of Windows 10 running VirtualBox 5.2.22. I'm using a MATE graphical desktop environment.

The weird behavior I'm seeing is that if I have a mate-terminal window that's covered by a "newer" window with focus (Firefox or another mate-terminal window), then when I attempt to click and drag (or select an area) on the newer window that's covering the original mate-terminal window, then I see highlighted regions appear on the covered window even though I'm clicking on the overlapping, newer window that has focus. Strange...

I can confirm this issue also happens with MacOS (Mojave) host and CentOS 7.6
I'm pretty sure this is not a host or GA issue, but related to the newest kernel.

Stepping back to kernel-3.10.0-862.14.4.el7.x86_64 solved the issue for me (both with GA 5.2.22 and 5.2.23)
with the newest kernel-3.10.0-957-1.3.el7.x86_64 with or without GAs (you need GA 5.2.23 , GA 5.2.22 fail to build), the Problem still occurs.

I wonder if it the same thing as this:

https://www.virtualbox.org/ticket/16562

I encountered this mouse problem after getting past a GA build issue.
As posted there, I ran across other threads (see kus post here that points to ticket here (user michael was involved with that ticket)) that give a workaround until a fix is found: kill the VBoxClient --draganddrop processes (there should be 2).

Ctrl-Alt-F2 (or Fn) to get to a console login if needed.
ps aux | grep VBoxClient
kill (only) those processes with the --draganddrop option.

michael wrote:I wonder if it the same thing as this: https://www.virtualbox.org/ticket/16562

No, it's not. I've had several CentOS versions (7.4, 7.5, 7.6) and only with 7.6 I've seen this. I got bitten myself yesterday while doing some OpenGL tests. Couldn't switch applications. It may be an X.org bug, sure, it simply wasn't manifested until now.

Change Nickname wrote:I encountered this mouse problem after getting past a GA build issue.
As posted there, I ran across other threads (see kus post here that points to ticket here (user michael was involved with that ticket)) that give a workaround until a fix is found: kill the VBoxClient --draganddrop processes (there should be 2).

Ctrl-Alt-F2 (or Fn) to get to a console login if needed.
ps aux | grep VBoxClient
kill (only) those processes with the --draganddrop option.

So, I decided to run 'yum upgrade' last night and ended up in a world of hurt once the 5.2.22 Guest Additions failed. I then sought out the test builds of Virtual Box. After getting the latest test builds of both Virtual Box and the guest additions (v5.2.23) to install, I encountered the mouse issue. Killing the --draganddrop processes resolved the issue.

Thank you!

For the people saying killing the drag and drop processes fixes the issue...do you mean permanently, or until you click an application again?

For me at least, DnD does not even enter the equation, it's disabled in the VM Settings.

rconde01 wrote:For the people saying killing the drag and drop processes fixes the issue...do you mean permanently, or until you click an application again?

I kill them when the problem arises (which is quick) and I'm pretty sure they stay gone (for that session).
Yesterday I did a preemptive kill after logon and it didn't seem to work, but this morning a preemptive kill did.
Since this is just an ad hoc workaround YMMV, but it has worked for me for several sessions.
As for socratis' info, maybe one needs to have DnD up and then kill it to get to the "fix".
It's certainly not clear that DnD is the ultimate culprit.