In seamless mode, mouse events do not reach host windows visible behind the VM -> fixed in 5.1.28

[j-za]

In VB 5.1.10 on an OS X 10.10.5 Yosemite host, when a Windows guest (Win 10, XP) in seamless mode has focus, clicking a host window that is visible "behind" the VM has no effect. Normally that would switch focus to the app that was clicked on.

Other mouse events that normally affect visible background windows (scrolling in particular) also have no effect.

Using Cmd+Tab works normally to switch to another app, so does clicking on the Dock icon for another app. Clicks on the menu bar also work as you'd expect, and so does clicking on any window that belongs to the foreground VM.

The abnormality can be confirmed using the OS X UI Element Inspector app, which reports attributes of the widget under the mouse pointer. Normally when the pointer is over a background host window, details of that window are shown. In this case however, it hardly matters where the pointer is: the entire screen is reported as a single screen-sized window owned by the VM, except for the menu bar and the Dock.

For comparison I tested versions 5.1.8 and 5.1.6 against the same VM's: neither of those showed this problem

[Socratis]

I can confirm the problem.

• Host: OSX 10.9.5.
• Guest: I only tested WinXP, could try more if asked.
• VirtualBox: 5.1.8 (works), 5.1.10 and 5.1.12 (fails).
• VBox.log: available for all versions, but they're identical. I could attach them if asked.

The description of the problem couldn't be more accurate (kudos j-za!). I could only describe it like a veil (or invisible window if you prefer) has taken over the desktop. Even if you click on an empty space of the VM (apparently) the "VM window" is there. The funny thing is that it doesn't even respect the z-order of the windows.

[z3rodivide]

Host: OSX 10.12.2

Guest: WinXP, Windows 7, Debian Linux

VirtualBox: 5.1.8 (works), 5.1.10 and 5.1.12 (fails).

I confirm this problem, I only add that icons on guest desktop are not responding too.

[xek]

I also confirm.

Host: OS X 10.12.2 (16C67) Guest: Windows 7 Virtualbox: 5.1.14 r112924 (Qt5.6.2)

[emu]

I also can confirm the bug.

Host: OSX 10.12.2
Guest: Debian Linux
VirtualBox: 5.1.12

[chazman]

I also confirm

Host: macOS 10.12.2 Guest: Windows 7 VirtualBox 5.1.8 (works), 5.1.10 (fails)

[Jason Hagar]

I can also confirm.

Host: macOS 10.12.3 VirtualBox: 5.1.14 Guest: Windows 10

[BerlinSnoop]

I can also confirm focus fail.

Host: macOS 10.12.3 (MacBookPro Late 2016 with external screen) VirtualBox: 5.1.14 Guest: Windows 10

[mariano.ivaldi]

I confirm the issue as well OS X 10.11.6, VirtualBox 5.1.22 r115126, Guest: Windows 7

Any updates on getting it fixed ?

[pallymdridge]

I confirm issue with OS X 10.12.4, VirtualBox 5.1.22, Guest: WinXP

[z3rodivide]

confirmed, issue still present VirtualBox 5.1.22 Host : OSX 10.12.5 Guest : Windows XP / Windows 7 64 bit / Linux CentOS

[Anth]

Issue still present in VirtualBox 5.1.22 on OSX 10.10.5 Yosemite. Guest: Windows 7 32-bit.

[DARKGuy]

This is still happening on VBox 5.1.22 r115126 under OSX Sierra 10.12.5. Tried with guests Windows 10 x64 and Windows 8.1 x64, same problem.

[ambarroy]

I am facing this issue with VirtualBox 5.1.22 on OS X El Capitan 10.11.6. Using Windows XP guest and with latest guest addons installed in the Guest OS.

In addition to mouse events not reaching the background windows, I have also noticed that in seamless mode, the menu bar will cover the top of the window. In past this was not the case.

[admin0130]

Same thing happening on macOS Sierra, works fine on 5.1.8 using windows 7 64-bit as guest.

[cj64]

Created an account to add to this thread. I've experienced the same issue using VBox 5.1.22 r115126 on OS X as host and using both Ubuntu and Windows 7 virtual machines.

I use seamless mode quite a bit and this bug effectively breaks it. Please consider this my vote to devote dev time to fixing the issue. Thanks!

[BerlinSnoop]

I can confirm this problem too. VBox 5.1.22 with host: macOS Sierra 10.12.5 , guest: windows 7 64-bit as guest. Please fix it ASAP! Many thanks

[dadama]

I confirm this ticket.

VirtualBox 5.1.22, Host: macOS 10.12.5, Guest: Windows XP SP3.

Have reverted to VirtualBox 5.1.8 as a workaround. Would be happy to upgrade when this is fixed.

[z3rodivide]

Virtualbox 5.1.26 Host : macOS 10.12.6 Guest : Windows XP, 7, 10 - various linux distros

issue still present

[itsatrap]

This is almost undoubtedly not a bug in VirtualBox itself. Instead, it's likely due to a bug introduced in Qt 5.6 (March 16th, 2016), and VirtualBox just happened to start being built with problematic versions of Qt starting at 5.1.10 (November 21st, 2016).

The Qt issue is in their tracker as 54830: ​https://bugreports.qt.io/browse/QTBUG-54830

There are patches for Qt 5.6 and Qt 5.9 available as attachments in the Qt tracker.

[Frank Mehnert]

itsatrap, thank you for the valuable information! We have added this patch to our Qt version.

To all: Please could you download the latest 5.1 Mac OS X test build >= 117298 and verify that this problem is fixed?

[Socratis]

Good work guys! Verified as working with 5.1.27 r117298 (Qt5.6.2). Guests tested:

• Windows XP SP3.
• Windows 7 SP1, both 32- and 64-bit.
• Windows 10 1507/10586.753, 32-bit crashed, but it was the only guest that was set to maximize in the 2nd monitor. When set to maximize on the 1st monitor, it worked as intended. Something completely unrelated I guess. Will investigate further...
• Mint 17.03 with Cinnamon.
• Fedora 25 with Gnome.

Even click-through works! ;)

One thing that I noticed is that when one of the guest windows gets the focus, all of them move in front (in the z-level). I don't know if this is what's supposed to happen (my money is on "yes"), but then again I've never used or plan to use seamless mode.

@itsatrap
Excellent job finding that reference! ​Admiral Ackbar would have been really proud! :D

[pallymdridge]

Version 5.1.27 r117332 (Qt5.6.2) appears to be working fine for me on Yosemite with a WinXP guest OS. Thanks!

[itsatrap]

Just a note that there has been movement on the ​Qt ticket. Specifically, the patch has ​been integrated into Qt 5.9 after passing review and CI, which it looks like is a necessary precondition for it to be fixed in upstream 5.6 as well.

@frank: Thanks for getting the patch applied. Can you share any notion of when we might see a release with the patch?

@socratis: Thanks for the verification. To respond to your note about guest windows all moving to the front when any one is activated: you're exactly right -- that's how seamless is implemented. All guest windows appear together in the host z-order because all guest windows are actually a single host window that covers (almost all of) the entire screen and is transparent in the places where guest windows don't actually appear. As you observed eight months ago: an ".. invisible window ... has taken over the desktop". That had always been the case, it's just that clicks stopped passing through the invisible parts. This differs from how other virtualization solutions do it, where they actually create independent host windows for each guest window. Both approaches have pros and cons. (As for the Windows 10 guest crash, I think you're probably right: it seems very unlikely that it's related.)

[ambarroy]

I am running 5.1.28 on OS X El Capitan 10.11.6 and while most of the problem has been fixed, there is still a small part of this bug that has not been fixed.

On my system I have 2 monitors. Spaces is set up so that the taskbar and dock are present on both the monitors and the 2 monitors dont have their spaces linked.

When I run a Windows VM in seamless mode, the mouse clicks go to the background, but the top part of the VM's window is covered by the OS X menu bar. This makes any window icons like system menu, close button, maximize/restore and minimise buttons along with the window titlebar hidden behind the OS X title bar.

I dont know if this is a related bug or a new one, so I am updating this old ticket.

[tom.salmon]

I believe this bug was re-introduced with both 5.1.30 and 5.2. I tested RHEL 7.4 and RHEL 6.9 on OSX 10.11.6 and the bug (or a related one) seem to be back. I finally reverted to 5.1.28 and everything works as expected.