Mouse integration and snap to default button in a guest OS

Description

Mouse integration is a great feature, but misses one piece: guest OS can not control position of mouse pointer. This can be easily verified in the Windows XP guest OS. Go to the Control Panel/Mouse, select 'Pointer Parameters' tab and check the 'Snap to default button' checkbox. After this, with mouse integration disabled mouse cursor will jump to the default dialog button (eg, the OK button). It will not however, with mouse integration enabled. This will also cause problems with programs which move mouse cursor programmatically and expect it to actually move.

Change History

This works like designed. The mouse cursor is a host resource and the host does not trust the guest. Therefore the guest is not allowed to change the host most mouse cursor position. If you need that feature, disable the mouse cursor integration temporarily (as you already found out).

I would just like to add a comment here too. Mouse integration works similarly to a touch screen. Imagine your Windows guest is running on a physical system with a touch screen but no external mouse. How would the feature you describe work in that environment?

Imagine how annoying it would be if an application in the guest tried to trap the mouse cursor (like VirtualBox does when you capture it). I realise that you may personally consider this less important than the snap-to feature, and I am sorry in that case, but as we have to consider a wide range of users and have very rarely heard complaints about this our decision was and remains to only allow that sort of thing in captured mode.

The snap-to feature was mentioned only as test case. The real application moves cursor as a response to zoom in/out action (mouse wheel events). As result, it works completely wrong in the integration mode. Still, would greatly appreciate if this feature could be enabled via command line or something like that.

What should I say - mouse integration can be disabled with a simple key combination or a couple of clicks in a menu, and we are not going to divert time from more urgent issues to add another option in this direction (which would incidentally require a significant amount of engineering work as it involves changes right the way through from Guest Additions to front-end and a communication protocol change). I assume that you are developing an application which this is relevant and testing it in VirtualBox. If my guess is right then you should really consider what happens when one of your users tries to interact with it via a touch screen or tablet (or other means of input).

No, I'm an end user of Windows only application. It still have issues with wine, so I have to run it in VB. And no, by nature of this application it have very little chances to run on tablet. Of course, if this feature requires that much work then there is no reason to implement it.