| 4 | | > Still an issue on 5.2.18. |
| 5 | | > |
| 6 | | > As previously mentioned, it only happens when 3D is enabled ''and the guest is using 3D'', and it affects all guest OSes (definitely Windows and Linux at least). The window frame and content do not detach until the desktop or login screen is displayed (presumably the VirtualBox guest 3D drivers activate at this point); the BIOS/EFI boot screen, OS boot loader, and Linux text consoles are unaffected. If I disable 3D support in a Linux guest (inside the guest -- 3D acceleration remains enabled in the VM settings), the problem never occurs (but performance suffers, obviously). |
| 7 | | > |
| 8 | | > Interesting detail: While in this "detached" state, launching Mission Control (Ctrl+UpArrow or F3) shows two separate windows for the VM: one titled '''VirtualBox VM''' showing the VM's desktop; the other '''''VM name'' [running]''' with the window frame and black screen. While in this state, if you move either to another desktop, switching to that desktop will kick you right back to Desktop 1. |
| 9 | | > |
| 10 | | > After minimizing and restoring the VM window, they are combined into one window with the VM's name, and you can move it between desktops as normal. |
| | 3 | Still an issue on MacOS Mojave |
