Duplicate MouseDown events

[SokoloffA]

Hello!

First of all, thank you so much for developing this application - I really appreciate your work on it! I’ve been using VirtualBuddy to test and fix an issue in my own project. I needed to test my app on macOS 27, and VirtualBuddy was the only tool that made that possible.

While testing, I noticed some unexpected behavior: clicking on the menu bar triggers two MouseDown events. The first event has a valid event.eventNumber, but the second one arrives with event.eventNumber equal to 0.

I’m not entirely sure whether this is an issue with the VirtualBuddy beta or a bug in macOS 27 itself, but I wanted to share my findings just in case.

Environment details:

• VirtualBuddy: Version 2.2 beta 2 (366)
• Host OS: macOS 26.5.1 (25F80)
• Guest OS: macOS Beta 27.0 (26A5378n)
• Tested Application: Radiola-2026.07.24_23.07.46.dmg

[yhay81]

There is a fairly strong VirtualBuddy-side lead here: in Trackpad mode, the current code presents two pointing devices to the guest:

case .trackpad:
    return [
        VZMacTrackpadConfiguration(),
        VZUSBScreenCoordinatePointingDeviceConfiguration()
    ]

In Mouse mode it presents only the USB screen-coordinate device. See the pointing-device configuration; that array is then assigned directly to VZVirtualMachineConfiguration.pointingDevices.

macOS 27 may now be translating the same menu-bar click from both virtual devices, with one path producing the normal event number and the other a synthesized event with eventNumber == 0. That would also explain why this is visible in VirtualBuddy but filtering all event-number-zero events breaks NoMachine.

A useful A/B test is:

1. Fully shut down the VM (do not resume a saved state).
2. Edit the VM → Hardware → Pointing Device and change Trackpad to Mouse.
3. Boot macOS 27 and repeat the same Radiola click/log test.

The setting is exposed in PointingDeviceConfigurationView. If the duplicate disappears in Mouse mode, that isolates the issue to the two-device Trackpad configuration (or a macOS 27/Virtualization.framework regression in handling it), rather than Radiola's menu logic. It would also give the maintainer a very small reproducer: compare one USB device with Mac trackpad + USB device.

I would not use eventNumber != 0 as the application fix. At most, Radiola could temporarily coalesce two same-button/same-location mouse-downs arriving within a very small interval, but the cleaner fix belongs at the VM/device layer. A candidate VirtualBuddy experiment would be to expose only VZMacTrackpadConfiguration for a macOS 27 guest (or otherwise avoid delivering both paths), while checking that absolute cursor positioning still works.

[insidegui]

Good point! (no pun intended)

I believe this was done way back in the day so that older OSes that didn't support trackpad would still work, but that's no longer needed since VirtualBuddy has gotten much better at detecting which features the guest supports. Will be addressing this!

[yhay81]

Thanks for confirming—that makes the duplicate-device explanation much stronger. The old compatibility fallback fits the eventNumber == 0 synthesized path very well.

@SokoloffA, the Mouse-mode A/B test is still useful as an immediate workaround/check. If this explanation resolves the original question, you can mark the top-level response as the accepted answer so the confirmed cause is easy for future readers to find.

[SokoloffA]

Previously, I had "Mouse" set as my "Pointing device" setting.
I tried changing it to "Trackpad," but nothing changed. I see two events.

[SokoloffA]

This is not a bug in your code.

• I installed macOS 27 in UTM and the issue reproduces there.
• AndreasRavn confirmed the behavior on real hardware as well.

Is it enough for me to just close the discussion, or should I also mark it as "resolved" or "not a bug"? If so, how?

Thanks again for the great app!

[insidegui]

Bummer, I really thought it could be resolved by just fixing that dual input-device configuration. I will flag your post as the answer but leave the discussion open in case someone finds a workaround that could be implemented in VirtualBuddy. Thank you!

[SokoloffA]

I'm not sure it's necessary to fix OS bugs in a virtual machine. The purpose of a VM is to emulate an OS as accurately as possible. Imagine you wrote a workaround, I tested my program, and happily published it. And then, bam! It doesn't work for other people, and I can't even debug it.