Unexpected closure of guest when clicking menubar item in fullscreen

[Will Pittenger]

About half the time when I click a menu bar item expecting it to open the menu, it closes the guest without any warnings whatsoever. That is VERY bad. The typical time I've noticed, I was either trying to open the View menu or the Devices menu.

In many ways, this is a crash--even if vBox thinks it was told to close. I was unsure of which component to chose. Someone may need to correct it.

The only guest/host combination this was noted with was Linux for the guest and Windows for the host. However, I expect this to affect all guests.

[Will Pittenger]

Sampe log file of such a close

[Frank Mehnert]

Your description sounds like a bug, the VM process seems to crash. However, we cannot reproduce the problem. The VBox.log.2 file you attached shows that the guest was powered off using the GUI. I would like to see a VBox.log file for a VM process which suddenly closed like you described.

[Will Pittenger]

That's what I attached. Sorry.

[Frank Mehnert]

I don't understand. If you power-off your VM from the GUI (e.g. menu "File" / "Close" / "Power off" then this is not a bug.

[Will Pittenger]

Except I didn't. All I did was click the full screen menu bar. It might have logged that it closed normally, but it didn't. I think it was confused. And there was NO warning about closing the VM without saving.

[Frank Mehnert]

Could you provide the VirtualBox.xml file which resides in C:\Users\USER\.VirtualBox as well as the .vbox of the VM settings?

[Will Pittenger]

vbox file for sample

[Will Pittenger]

Settings file

[CM7]

I would like to add an observation that I believe might be at the root of this reported problem as I have experienced it myself. I've been struggling how or whether to even report it, but I believe this case may be the same.

I hope the OP will confirm, I think this is a UI design problem that occurs when the guests' mini-toolbar is set to show at the bottom of the screen (show at top of screen: unchecked). In this particular configuration, hovering and clicking the mouse near the bottom of the screen can cause the guest hidden mini-toolbar to appear while clicking then inadvertently activate a menu item that happens to appear underneath the mouse at the time while completing the "click-release" action (which is technically actually 2 actions: press and release, mouse "click" actions actually being initiated upon release).

The 2 menu items that are most easily and inadvertently initiated here are:

1) File; "Close", 2) Machine; "ACPI Shutdown".

When the mini-toolbar appears at the bottom of the screen, these two actions (among others) can flash (so fast they may not even be seen) underneath the mouse pointer while being clicked.

When the mini-toolbar is at the top of the screen, no actionable menu item appears under the mouse pointer (this is correct and safe design, IMO).

This is where the UI design for the mini-toolbar at the bottom of the screen is flawed in my opinion: since actionable menu items can pop-up under the mouse pointer while hovering and clicking, undesirable actions can be initiated inadvertently by any mis-clicks at the bottom of the screen. Mistakes are easy here since the hidden toolbar has multiple sensitive activities: hover (reveals hidden toolbar), click (before/during/after unhide), release (activates any menu item that appears under the mouse pointer at that point).

Compare the screen shots I've attached that show the top menu (no action item appears under the mouse where the toolbar appeared) and those at the bottom of the screen (where 2 undesirable actions can appear under the mouse pointer and activate inadvertently depending on the hover/click/release sequence.

I recommend anyone can test this scenario: with the toolbar at the top, try moving the mouse to the top of the screen, and just click. No danger here. Then change the toolbar to the bottom of the screen, move the mouse down there and (carefully) click (don't release until you see where the menu pops-up). Scary, huh? If you don't see it the first time, try different speeds of hovering to the bottom, pausing, clicking, and releasing, including all fast or deliberately slow each action.

I think a small UI design change could prevent inadvertent shutdown from this: for the bottom toolbar, make sure that all menu items appear above instead of over the main mini-toolbar menu, similar to the top one where any actionable menu items appear below the toolbar.

[CM7]

Toolbar Top

[CM7]

Toolbar Bottom - File

[CM7]

Toolbar Bottom - Machine

[Frank Mehnert]

This explanation sounds plausible and I guess the menubar design can be improved. At the moment I see the following workaround: Disable the automatic toolbar and use the HostKey+Home key combination to display the menu in fullscrenn/seamless mode.

[Will Pittenger]

I agree. To bad it isn't possible for me to move the menu bar to the top due to conflicting use of space on the host. As for future changes, I've requested the status bar "lights" be added to the bar on IRC. Those are hidden in full screen mode.

Replying to CM7:

I would like to add an observation that I believe might be at the root of this reported problem as I have experienced it myself. I've been struggling how or whether to even report it, but I believe this case may be the same.

I hope the OP will confirm, I think this is a UI design problem that occurs when the guests' mini-toolbar is set to show at the bottom of the screen (show at top of screen: unchecked). In this particular configuration, hovering and clicking the mouse near the bottom of the screen can cause the guest hidden mini-toolbar to appear while clicking then inadvertently activate a menu item that happens to appear underneath the mouse at the time while completing the "click-release" action (which is technically actually 2 actions: press and release, mouse "click" actions actually being initiated upon release).

The 2 menu items that are most easily and inadvertently initiated here are:

1) File; "Close", 2) Machine; "ACPI Shutdown".

When the mini-toolbar appears at the bottom of the screen, these two actions (among others) can flash (so fast they may not even be seen) underneath the mouse pointer while being clicked.

When the mini-toolbar is at the top of the screen, no actionable menu item appears under the mouse pointer (this is correct and safe design, IMO).

This is where the UI design for the mini-toolbar at the bottom of the screen is flawed in my opinion: since actionable menu items can pop-up under the mouse pointer while hovering and clicking, undesirable actions can be initiated inadvertently by any mis-clicks at the bottom of the screen. Mistakes are easy here since the hidden toolbar has multiple sensitive activities: hover (reveals hidden toolbar), click (before/during/after unhide), release (activates any menu item that appears under the mouse pointer at that point).

Compare the screen shots I've attached that show the top menu (no action item appears under the mouse where the toolbar appeared) and those at the bottom of the screen (where 2 undesirable actions can appear under the mouse pointer and activate inadvertently depending on the hover/click/release sequence.

I recommend anyone can test this scenario: with the toolbar at the top, try moving the mouse to the top of the screen, and just click. No danger here. Then change the toolbar to the bottom of the screen, move the mouse down there and (carefully) click (don't release until you see where the menu pops-up). Scary, huh? If you don't see it the first time, try different speeds of hovering to the bottom, pausing, clicking, and releasing, including all fast or deliberately slow each action.

I think a small UI design change could prevent inadvertent shutdown from this: for the bottom toolbar, make sure that all menu items appear above instead of over the main mini-toolbar menu, similar to the top one where any actionable menu items appear below the toolbar.

[adesanctis]

I'm experiencing a similar issue with VB 5.1 and GA 5.1. When I try to modify scale factor VB craches and is reported as "aborted" in the manager No error is reported in the log:

00:01:08.322931 Switching Gl mode off
00:01:08.322986 GUI: UIMachineViewScale::resendSizeHint: Restoring guest size-hint for screen 0 to 1536x864
00:01:08.339395 GUI: UIMachineView::sltHandleNotifyChange: Screen=0, Size=1536x864
00:01:08.339417 GUI: UIFrameBufferPrivate::handleNotifyChange: Size=1536x864
00:01:08.339456 GUI: UIFrameBufferPrivate::performResize: Size=1536x864, Directly using source bitmap content
00:01:08.339533 GUI: UIMachineView::storeGuestSizeHint: Storing guest-screen size-hint for screen 0 as 1536x864
00:02:20.741847 RTC: period=0x200 (512) 64 Hz
00:04:46.070484 RTC: period=0x20 (32) 1024 Hz
00:04:46.085479 RTC: period=0x200 (512) 64 Hz
00:05:34.305118 RTC: period=0x20 (32) 1024 Hz
00:05:34.491527 RTC: period=0x200 (512) 64 Hz
00:25:55.085929 PCNet#0: Init: ss32=1 GCRDRA=0x0a482420[64] GCTDRA=0x0a482020[64]

When I activate scaled mode I have on the first time the vm to abort, but in the next times problems seems to be solved... The problem persists on other VMs that I didn't scaled

Hope this is useful