VirtualBox

Ticket #16246 (closed defect: fixed)

Opened 12 months ago

Last modified 6 days ago

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

Reported by: j-za Owned by:
Priority: major Component: GUI/seamless
Version: VirtualBox 5.1.10 Keywords: seamless mouse
Cc: Guest type: Windows
Host type: Mac OS X

Description

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

Change History

comment:1 Changed 11 months ago by 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.

comment:2 Changed 11 months ago by 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.

comment:3 Changed 10 months ago by xek

I also confirm.

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

comment:4 Changed 10 months ago by emu

I also can confirm the bug.

Host: OSX 10.12.2
Guest: Debian Linux
VirtualBox: 5.1.12

comment:5 Changed 10 months ago by chazman

I also confirm

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

comment:6 Changed 9 months ago by jsdev

I can also confirm.

Host: macOS 10.12.3 VirtualBox: 5.1.14 Guest: Windows 10

comment:7 Changed 9 months ago by 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

comment:8 Changed 7 months ago by 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 ?

Last edited 7 months ago by mariano.ivaldi (previous) (diff)

comment:9 Changed 6 months ago by pallymdridge

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

comment:10 Changed 6 months ago by z3rodivide

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

comment:11 Changed 6 months ago by Anth

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

comment:12 Changed 6 months ago by 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.

comment:13 Changed 6 months ago by 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.

comment:14 Changed 5 months ago by admin0130

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

comment:15 Changed 5 months ago by 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!

comment:16 Changed 5 months ago by 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

comment:17 Changed 5 months ago by 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.

comment:18 Changed 4 months ago by z3rodivide

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

issue still present

comment:19 Changed 4 months ago by 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.

Last edited 4 months ago by itsatrap (previous) (diff)

comment:20 Changed 4 months ago by frank

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?

comment:21 Changed 4 months ago by 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

comment:22 Changed 4 months ago by pallymdridge

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

comment:23 Changed 4 months ago by 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.)

comment:24 Changed 2 months ago by michael

  • Status changed from new to closed
  • Resolution set to fixed
  • Summary changed from In seamless mode, mouse events do not reach host windows visible behind the VM to In seamless mode, mouse events do not reach host windows visible behind the VM -> fixed in 5.1.28

comment:25 Changed 5 weeks ago by 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.

comment:26 Changed 6 days ago by 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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use