Mouse wheel scrolling usually not working, cursor off, hotkeys not sent to vm, after moving to edge of screen

[basic6]

This is not a new issue but I couldn't find a related bug report that's still open.

I believe the following issues may be related.

A) Mouse wheel scrolling usually doesn't work while "mouse integration" is not active (input captured). It always works fine at first, right after clicking or hitting Ctrl in the VM window to capture both mouse and keyboard. At some point, it stops working. Hitting Ctrl to release the mouse reveals that the host's mouse cursor is usually about half a screen away from the VM's cursor. After moving the host's cursor back to where the VM's cursor is and then clicking to recapture the input, it works again. But not for long. This is happening so often that I tend to not use the mouse wheel at all and use the good old scrollbar buttons instead. Unfortunately, some desktop environments (Gnome/GTK) have lost the scrollbar buttons for whatever reason. In that case, the combination of a temporarily broken scroll wheel *and* a broken scrollbar makes it rather difficult to navigate through content (vertically and horizontally).

B) Whenever a VM is started, mouse integration is active by default, which means the VM's cursor is moved together with the host's cursor as long as it's within the VM window without requiring the user to click into the VM window first. Unfortunately, the cursor is often way off. Sometimes even a third cursor would fit between the host's and the VM's cursor. I'll attach a screenshot. This is one of the reasons why I usually disable mouse integration after starting a VM. But then, the first issue happens.

C) While mouse integration is active, hotkeys often don't work, i.e., they're not sent to the VM. For example, after starting a VM, you'd hit Alt + Tab while working inside the VM and you get the host's task switcher showing your open Virtualbox windows. What you actually wanted to do is switch windows inside the VM. You have to first click somewhere inside the VM and then hit Ctrl to temporarily capture the keyboard and send hotkeys to the VM. I say temporarily because at random times, apparently when moving the cursor to the edge of the screen (but strangely not always), it stops working again and the next time Alt + Tab is used, it's sent to the host again. This is the main reason why I have to disable mouse integration after starting a VM and then only interact with the VM with mouse and keyboard captured and locked inside the VM window.

D) This is just a minor glitch. I don't remember when I first noticed that but it wasn't always like this. The user interface bar at the top of the screen gets stuck, covering that area in the VM. That's particularly annoying if the DE's panel (task bar) is at the top of the screen. This is solved by moving the host's cursor over the user interface panel and back in the VM, then it disappears normally.

E) This is not a glitch, just a note: When mouse integration is disabled but the input controls are *not* captured (e.g., VM on one monitor, host applications on another monitor), most keystrokes are still sent to the guest system (of course no hotkeys) while the VM window is focused. This may be counterintuitive because not having clicked into the VM window means that the user does not want to interact with it. Accidentally moving the host's mouse to the VM window may change the focus and then hitting space may active a button in the guest instead of inserting a whitespace in a host application window.

If it makes a difference, most VM windows are used in full screen mode. There may be a second or third monitor with other VMs or host application windows running.

Again, I am under the impression that the issues described above may be symptoms of one general issue. It appears that the VM window sometimes loses the input controls while the user is working with the VM or they get "out of sync" unexpectedly.

This behavior has been seen on different systems, but most recently on Debian, currently running Virtualbox 5.1.38. Some guest systems are running Fedora 28.