VirtualBox

Ticket #2613 (closed defect: fixed)

Opened 6 years ago

Last modified 3 weeks ago

Host key (ctrl) sometimes gets stuck down in Windows guest -> fixed in 4.3.24

Reported by: myxiplx Owned by:
Priority: minor Component: other
Version: VirtualBox 2.0.4 Keywords: ctrl host key stuck
Cc: Guest type: Windows
Host type: Linux

Description (last modified by michael) (diff)

Not all the time, but regularly enough to be a nuisance, the host key gets stuck down within the guest after it's been used to free up the mouse. Does VirtualBox always send the "key-up" message to the guest after the host key has been pressed?

I'm running VirtualBox full screen on my second monitor, and often hit ctrl so that I can leave the virtual machine running, but free the mouse so I can continue working on my primary screen.

After doing this, about a quarter of the time, I go back to the guest to find the control key stuck down. It means typing is impossible, and unlocking a machine with your password is a nuisance until you spot what is going on. Tapping the left control key on the keyboard does seem to free it up again.

I also run the VMware Infrastructure Client within this virtual machine, and that requires the use of Ctrl+Alt to free the mouse from its client windows. A couple of times now that has wound up locking the mouse and keyboard within VirtualBox when I come back to it, and it appears to coincide with times the control key has gotten stuck down. I'm reporting this here instead of as a separate bug as I think it's just another symptom of the same problem.

For now I've changed my host key to the Scroll Lock button, that appears to be a useful workaround for now.

Attachments

keylook.exe Download (18.0 KB) - added by michael 19 months ago.
winxp.png Download (42.9 KB) - added by mhanor 2 months ago.
Alt becomes unstuck
winxp2.png Download (29.1 KB) - added by mhanor 2 months ago.
the ; key becomes stuck, then unstuck
AutoHotkey Script.ahk Download (951 bytes) - added by mhanor 2 months ago.
winxp3.png Download (331.8 KB) - added by mhanor 2 months ago.
keysim.sh Download (152 bytes) - added by mhanor 2 months ago.
to reproduce on linux

Change History

comment:1 Changed 3 years ago by arencambre

I'm running into the same problem, 3 years later. :-) Has there been any progress on this?

comment:2 Changed 3 years ago by rrt

I have noticed the same problem with Alt getting stuck down in the guest after using Alt+Tab in seamless mode with keyboard capture switched off, so that the host always gets the keystroke.

Using Ubuntu 12.04 host, Windows 7 guest.

It can be cleared by pressing Alt again in the guest, but it makes seamless mode use unreliable.

comment:3 Changed 3 years ago by rrt

I can confirm the same problem in fullscreen mode (again with keyboard capture switched off).

comment:4 Changed 3 years ago by Bo

This has happened to me since about the 4.1.16 release. I run Ubuntu as my base system and use Windows 7 as the VM. Windows 7 behaves pretty well. The toggling from Windows back to Ubuntu is not as smooth as it used to be and the workspaces now behave oddly in 4.1.22. I wish at had stayed with the earlier variations of release 4. Still, a great product and thanks for the hard work.

comment:5 Changed 3 years ago by BJCubsFan

I have seen this problem using an Arch linux host and a Windows XP guest. The only way I could solve this was to pause and unpause the host machine. After that, the problem went away!

comment:6 Changed 2 years ago by Dtremblay

Same problem here. Host Windows 7 and Guest Windows XP. The key up message seems to get lost somewhere.

comment:7 Changed 2 years ago by rogerdpack

Dunno if it's the same problem, but with Windows 7 + Linux guest, sometimes when I "leave" the guest, the ctrl key for windows thinks it's down when it's not! (often enough to be annoying...) thanks! -r

comment:8 Changed 2 years ago by mosimu

This sounds like Sticky Keys. The following might help:

Open the Control Panel on Windows 7 host > Ease of Access > "Change how your keyboard works" > "Set up Sticky Keys"

Uncheck the option "Lock modifier keys when pressed twice in a row."

When your Ctrl or Alt key is stuck on the host, you should be able to unstick by holding down both Ctrl and Alt at the same time, then releasing. This works because of the other option you see in Control Panel, "Turn off Sticky Keys when two keys are pressed at once."

comment:9 Changed 2 years ago by rrt

It's not StickyKeys, at least in my case (I'm not even using a Windows host).

Last edited 2 years ago by rrt (previous) (diff)

comment:10 Changed 2 years ago by michael

  • Description modified (diff)

If it is not sticky keys on the host then you should be able to make it go away (I am not suggesting that this is a solution to the problem) using the command line command "VBoxManage controlvm keyboardputscancode <code>", where "code" is the hexadecimal scan code value (PS/2 scan code that is) of the key which is stuck. This page<1> has a list of hexadecimal scan codes for all standard keyboard keys.

<1>  http://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html

comment:11 Changed 2 years ago by michael

I have uploaded a test build which contains a fix which may possibly fix this issue.

 http://www.virtualbox.org/download/testcase/VirtualBox-4.2.13-85236-Win.exe

comment:12 Changed 2 years ago by ccijwlrjqj

I've also noticed the ESC key to be stuck on the Windows host sometimes, after leaving a guest.

To work around it, pressing and releasing (after one another) the ESC, CTRL, and ALT keys on the Windows host works.

comment:13 Changed 23 months ago by Tsso2

THANK YOU!!! FOUR+ YEARS OF SUFFERING FROM THIS BUG ARE FINALLY OVER!!!

It's so bad, I've developed a reflex to hit the windows key twice every time I switch out of the VM. But it's finally fixed! Thank you!

comment:14 Changed 23 months ago by michael

  • Summary changed from Host key (ctrl) sometimes gets stuck down in Windows guest to Host key (ctrl) sometimes gets stuck down in Windows guest -> fixed as of May 2013 in 4.2.x and later

comment:15 Changed 22 months ago by frank

  • Status changed from new to closed
  • Resolution set to fixed

Fix is part of VBox 4.2.14.

comment:16 Changed 21 months ago by rrt

  • Status changed from closed to reopened
  • Resolution fixed deleted

In VirtualBox 4.2.14 on Linux the bug is still present, at least for the Alt key: pressing Alt+Tab to switch from a VirtualBox OS window to a host window frequently leaves Alt in a "down" state in the VirtualBox OS window.

Version 0, edited 21 months ago by rrt (next)

comment:17 Changed 21 months ago by rrt

This bug could usefully be retitled: first, to note that the fix was for Windows hosts only, and secondly, that it was in 4.2.14. I suggest changing: "fixed as of May 2013 in 4.2.x and later" to "fixed for Windows hosts in 4.2.14".

comment:18 Changed 21 months ago by michael

  • Summary changed from Host key (ctrl) sometimes gets stuck down in Windows guest -> fixed as of May 2013 in 4.2.x and later to Host key (ctrl) sometimes gets stuck down in Windows guest

Indeed, you are right. What was fixed was a different bug on Windows hosts, whereas this one explicitly affects Linux hosts. Shame on me.

comment:19 Changed 19 months ago by rogerdpack

I for one am glad the windows bug was fixed (I assumed they'd be part of the same problem/fix, but I guess they weren't?). Anyway so now this ticket is specifically targeted to linux host having the same problem, which is apparently still present. Got it. Thanks for the fix though.

comment:20 Changed 19 months ago by michael

Is anyone currently affected by this issue on a Linux host? If so, is your issue exactly what is described in the ticket summary or something different? And if it is, what input/mouse focus policy are you using on your Linux host?

comment:21 Changed 19 months ago by rrt

I am affected by this issue on a Linux host. My exact problem is as described in comment 2 (i.e. I notice it with the Alt key rather than the Host key, but that's only because I don't use the Host key).

I use click to focus (which seems to be the default these days on most GNU/Linux systems).

comment:22 Changed 19 months ago by michael

I was not able to reproduce this with an Ubuntu 13.04 host and guest. Could you please give precise steps to reproduce with this combination if that is reasonably possible?

comment:23 Changed 19 months ago by rrt

As per comment 2, I'm using Ubuntu host (now 13.04) and Windows 7 guest. Alt gets stuck down in the guest almost every time I Alt+Tab away from the VM window to some other Ubuntu window; to ensure it sticks, make sure Alt is held down for about 0.5s (sometimes if I release it quickly it doesn't stick down in the guest). The effect is easily visible e.g. in Word 2013 in the guest, because the labels that pop up when you press Alt are still visible in the guest VM window after it's lost the focus.

comment:24 Changed 19 months ago by michael

Can you reproduce this with a Linux (Ubuntu?) guest too? I am wondering whether this might be some peculiarity of your Windows guest, as I was unable to reproduce it with an Ubuntu guest, but that sort of behaviour shouldn't depend on the guest system at all. And do you release the keyboard capture before Alt-Tab-ing away from the guest, or do you have it disabled altogether?

comment:25 Changed 19 months ago by rrt

I don't have any Linux guests. However, further experimentation shows that it seems to be a problem specifically with Word 2013 (it clearly previously affected some other application, probably Word 2003, which is what I had when I reported the bug.) Other apps (e.g. Chrome, Notepad) don't exhibit the problem.

I have keyboard capture switched off, precisely so I can use Alt+Tab to switch host windows, not guest windows.

comment:26 Changed 19 months ago by michael

From your description this sounds more like an issue with the application than with VirtualBox. If it were, the problem should exist for all applications. You might try out the "keylook" tool <1> which will show you pretty clearly what input the guest is getting.

<1>  ftp://ftp.charlespetzold.com/ProgWin30/CHAP03/KEYLOOK.EXE

comment:27 Changed 19 months ago by rrt

I am unclear how this could be a problem with the application. This problem does not occur when the application is not running under a VM, it's not supposed to be the application's problem that it is running under a VM, and it doesn't seem very likely that the app would behave differently in this instance when running under a VM. Equally, assuming that all apps should behave the same seems like speculation to me; and clearly, some other apps suffer the same problem, as I wasn't running Word 2013 when I first noticed the bug.

I tried running KEYLOOK.EXE in my Windows 7 guest, and got the error: "The version of this file is not compatible with the version of Windows you're running." (I'm using Windows 7 64-bit, and an alternative error message from running the program from cmd.exe suggests that's the problem.) Searching didn't find me a 64-bit compatible version.

comment:28 Changed 19 months ago by michael

I found a version of keylook.exe which worked on a 64-bit Windows 7 and tested it myself. The guest indeed sees the "Alt" key up event, but I see that we also send another, spurious event before that one. Perhaps that is what is confusing MS Word.

comment:29 Changed 19 months ago by michael

Checking our source code I see that the spurious key release event before the "Alt" key up is there to stop Windows from seeing "Alt" pressed and immediately released and triggering unwanted actions, such as activating the menu (which usually happens if "Alt" is pressed and released). Unfortunately the event code we send used to only be used an error code, but is now also used by Brazilian keyboards (was that understandable?), which may be what is confusing Word. Not sure what the best solution is here, as you probably don't want your menu activated when you "Alt-Tab" out of the guest, but you probably don't want an "Alt-Tab" inside the guest either. And we can't hide the original "Alt" key down, as we do not know in advance that it is part of an "Alt-Tab".

comment:30 Changed 19 months ago by rrt

Thanks very much for continuing to investigate this problem. Perhaps you could post here (or even add to the VirtualBox documentation) a link to the Windows 7 version of keylook, as it sounds useful for debugging other key problems.

I am using a UK keyboard, so that code only run for Brazilian keyboards should not be a problem for me. I also cannot see why sending two key up events should be a problem, unless there is a bug in Word. Does the fact that timing seems to be important (i.e. if I hold down Alt for < 0.5s, I often don't get the problem) suggest any other lines of thought?

Just thinking about the particular problem here, I am unsure why it is quite so complicated. It would seem that what is needed is something like this:

  1. Modifier is pressed with guest OS focussed, key down event is generated.
  1. Non-modifier is pressed, and key combination is trapped by host OS; VirtualBox detects this situation, and sends a key up event to the guest.

I am unsure what the benefit of the extra key up event is: if I hold down Alt and wait for 1s before pressing Tab, then of course the guest should receive Alt keydown, and the Windows menus should activate. When I press Tab, that combination is trapped by the host, so will never reach the guest anyway. If the code is correct, it sounds like it is designed to deal with some other situation. In particular, I don't see how you can send the "spurious" Alt keyup event "early" enough to prevent Windows from e.g. displaying menus, as it seems to me the earliest you can send it is at the time when you can send the "correct" keyup event.

comment:31 Changed 19 months ago by michael

The source code of keylook is at:

 ftp://ftp.charlespetzold.com/ProgWin30/CHAP03/KEYLOOK.C

Windows does not know that you have a UK keyboard, only that you are using a UK layout - but Brazilian keyboards are physically different, and the only way Windows can tell you have one is when it sees key events for keys which don't exist on other keyboards. I will upload a build of keylook which works on Windows 7 64-bits.

Changed 19 months ago by michael

comment:32 Changed 19 months ago by michael

Just to test this to see if that really is the problem I have created a couple of special builds (which I haven't actually tried myself...), one of which completely removes the additional key event, and the second of which replaces it with a down and up of the "ESC" key. I can't say at this stage whether we would actually make such a change, as I am not aware of anyone else who has issues with this, but changing it might well affect people. Still, I am interested in your feedback.

Note: these are "makeself" shell script installers. You should uninstall your current VirtualBox installation before installing one of them. They can be uninstalled using the uninstaller script in the "/opt/VirtualBox*" folder. You should download them using right click and "Save as", or your browser may detect them as text and try to show them in a tab.

https://www.virtualbox.org/download/testcase/VirtualBox-4.2.19-88967-Linux_amd64.run https://www.virtualbox.org/download/testcase/VirtualBox-4.2.19-88970-Linux_amd64.run

comment:33 Changed 19 months ago by rrt

The first image (88967) produces behavior that I can reproduce with Notepad (and Word 2013 behaves the same): every time I press Alt+Tab, Windows behaves as if Alt had been pressed and released, i.e. the menus are highlighted the first time, unhighlighted the second time, etc. There is no dependence on a delay etc. This is not quite what I want, but is at least now consistent across applications and regardless of my timing.

The second image (88970) does exactly what I want: the Alt keystroke is effectively cancelled by the Escape each time I leave Windows.

comment:34 Changed 18 months ago by Willie

I can confirm this bug on Virtualbox 4.2.18, running Arch Linux 64 bit, Host OS is Win8 64 bit. I managed to reduce it a bit by setting scroll lock as the host key, but a stuck ctrl key still happens every now and then.

comment:35 Changed 11 months ago by guntheranon

I can confirm this bug on Virtualbox 4.2.18 r88780 on Ubuntu 12.04 64 bit. Guest OS is W7 64 bit. It doesn't happen all the time but when it does it is annoying as all get out.

I found that using the on screen keyboard helps identify when the buttons are stuck. For me it seems that Ctrl, Windows key, Alt, Shift all get stuck and they seem to stick only until another of these keys is pressed. i.e. Ctrl stays stuck until I press Alt or Shift or Windows key and then that key is stuck down.

I have also found that pressing Esc or Tab releases the stuck key but the key will stick immediately again when I press one of those problem keys. Sticky Keys is not on and I tried enabling and disabling the sticky keys feature.

comment:36 Changed 11 months ago by michael

Unless this is related to control getting stuck down when you alt-tab away from a virtual machine this is a different issue - perhaps you could open a new ticket for it and attach a machine log file?

comment:37 Changed 2 months ago by simonpie

I still have this problem every day all the time. I have two Windows virtual machines running full screen in a second monitor, each in their own space. The host key (which is the default right control) and the alt key will regularaly stay stuck. I have to depress for two seconds control or alt for it to unstuck. The problem is bad enough that every time I click in windows, they restuck again. Making me, of course go mad. The key also stay stuck even in debian. I have had this problem for over a year now. This ticket definetly should still be opened.

I run a debian, jessy, which I update every few days and Virtual box 4.3.12.

comment:38 follow-up: ↓ 45 Changed 2 months ago by michael

Just to be sure, might this be some accessibility setting in the Windows guests? Can you try investigating with the keylook.exe tool (inside the guest) attached to this ticket? And can you find a reproducible way to trigger this?

comment:39 Changed 2 months ago by rrt

This bug is really easy to reproduce on an Ubuntu 14.04 host (or indeed any earlier Ubuntu for the last N years) and Windows 7 guest (previously Windows XP guest): simply hold down Alt in the guest for longer than about a second, and then press Tab. The Alt+Tab is captured by the host, to switch windows. When I switch back to the guest, the Alt key is still treated as being held down, so for example menu shortcuts are visible.

If I switch away from the guest with a very quick keystroke (say, less than ½ second), it doesn't result in the Alt key being held down in the guest.

This behaviour is reliable for me, except that sometimes Alt+Tab is interpreted by the guest instead of the host, for no reason I can discern.

I am using Ubuntu 14.04's package of VirtualBox 4.3.10.

comment:40 Changed 2 months ago by michael

Not reproducible here with an Ubuntu 14.10 host and the official 4.3.20 build. I still wonder whether this is a Windows accessibility setting. The long key presses that people mention point to that to my mind.

comment:41 Changed 2 months ago by mhanor

There's an old bug I have reported here, where a key (including Alt) can become stuck in the guest. It becomes unstuck at the first key press in the guest. It's also visible in the keylook.exe tool. I'm attaching a screenshot. At the moment of pressing the a key, I wasn't pressing the Alt key. I also don't have any reason to mislead you. I can reproduce the issue on any of the host OSes I currently use (Ubuntu 14.04 x64, Windows 8.1 x64). It also doesn't have anything to do with the guest OS type.

To reproduce, you have to press a key (any key), release it, then press the Host key, release the Host key, in a very fast succession. When pressing and releasing the 'any' key, pressing and releasing the Host key, it's almost instantaneous, I'm not sure exactly if the key release is overlapping with the Host key press/release.

Last edited 2 months ago by mhanor (previous) (diff)

Changed 2 months ago by mhanor

Alt becomes unstuck

Changed 2 months ago by mhanor

the ; key becomes stuck, then unstuck

comment:42 follow-up: ↓ 47 Changed 2 months ago by michael

mhanor, do you also see the same behaviour as the other two reporters, where it needs a long key press to trigger the bug and a long key press to release the key again? Not suggesting that anyone is trying to mislead us by the way.

rrt, what is your host key?

comment:43 Changed 2 months ago by michael

And reversing my previous question as well, rrt and simonpie, does mhanor's ticket #11392 look like it could be your issues?

comment:44 Changed 2 months ago by mhanor

In my case, the long key press is needed for the Alt key (as the key to become stuck), under Ubuntu (as host), because if I do a short press/release of it, Ubuntu brings up the overlay HUD (I think that's what it's called). But if I press and hold the Alt key, in the guest, for as long as I want, and then I press Tab, even repeatedly, without ever releasing the Alt key, the guest catches that, not the host, which is different from what rrt reported above. Otherwise, I can reproduce the issue with the fast succession (maybe overlapping) of key presses and releases, I don't need to do long key presses to reproduce or to unstuck the key. The long key presses that they say are needed to reproduce the issue, or to release the stuck key, might indicate some other issue. Or maybe they misinterpret the situation and their actions.

Last edited 2 months ago by mhanor (previous) (diff)

comment:45 in reply to: ↑ 38 Changed 2 months ago by simonpie

Replying to michael:

Just to be sure, might this be some accessibility setting in the Windows guests? Can you try investigating with the keylook.exe tool (inside the guest) attached to this ticket? And can you find a reproducible way to trigger this?

I cannot find keylook.exe for windows 7 64 bits with a quick google search. I will look at the accessibility settings. Just to add a few details, I had the exact same behaviour with four different windows vms, two XPs and two Windows 7 which were independent image we use here where I work. And before running Jessy, I had the standard wheezy which had the exact same problem.

comment:46 Changed 2 months ago by michael

The keylook.exe binary attached to this ticket should work in Windows 7 64-bits too.

comment:47 in reply to: ↑ 42 Changed 2 months ago by simonpie

Replying to michael:

mhanor, do you also see the same behaviour as the other two reporters, where it needs a long key press to trigger the bug and a long key press to release the key again? Not suggesting that anyone is trying to mislead us by the way.

rrt, what is your host key?

To trigger the behaviour, I just need to click into Windows anywhere. Very often, when I switch space, where it be by clicking or host key followed by short-cuts to change space, when I come back and click into the windows space, or use short-cuts and then click a windows app, whith high probability something will get stuck (alt or control or both).

comment:48 Changed 2 months ago by rrt

My host key is Right Ctrl. One of the custom fixes you (michael) made in comment 32 (a custom 4.2.19) worked fine (as I said in comment 34). As soon as I went back to using a standard version, the bug came back. I have no Windows accessibility features activated as far as I know.

Thanks very much for continuing to work on this!

Since my problem doesn't involve the host key, it doesn't seem to be the same as #11392.

I tried keylook.exe and it's interesting: the delay required to trigger the problem seems to be the autorepeat delay: after that, the Alt key continues to register multiple copies in the keylook window, even though the keyboard focus has now changed to the Ubuntu window switcher. I didn't think modifier keys should auto-repeat…

comment:49 Changed 2 months ago by mhanor

In my case, keylook also reveals that the key becomes unstuck when the VM window looses focus (on my Windows host, at least).

Changed 2 months ago by mhanor

comment:50 Changed 2 months ago by mhanor

Here's an AutoHotkey script that should help you reproduce the issue on Windows. Start a VM, then the script. Always keep the VM window out of focus, by clicking the desktop, the taskbar or some other window, before pressing an AutoHotkey hotkey. There are two hotkeys available. The CTRL+Numpad0 hotkey should trigger the issue (it does in my case), while CTRL+Numpad1 will not.

Last edited 2 months ago by mhanor (previous) (diff)

comment:51 Changed 2 months ago by michael

You might want to give test build<1> revision 97963 a try (the fix is removed from later revisions for now). I think it will fix at least mhanor's issue.

<1> https://www.virtualbox.org/wiki/Testbuilds

comment:52 Changed 2 months ago by rrt

Once again, that fixes it for me!

comment:53 Changed 2 months ago by mhanor

I can't reproduce the issue either, but keylook shows me two consecutive key-up events for the same key. You can use the CTRL+Numpad0 hotkey of the same AutoHotkey script to see it with keylook.

Last edited 2 months ago by mhanor (previous) (diff)

comment:54 Changed 2 months ago by michael

I don't currently have a Windows guest handy. Could you provide a screen shot or type in the relevant information about which keys that happens for?

Changed 2 months ago by mhanor

comment:55 Changed 2 months ago by mhanor

It's the key that gets stuck when using the previous VirtualBox builds.

comment:56 Changed 2 months ago by michael

Does this happen if you press any key, or do you need to do something to trigger it?

comment:57 Changed 2 months ago by mhanor

It happens when I do the exact same thing I did to reproduce the stuck key with the previous builds. That includes using the AutoHotkey script CTRL+Numpad0 hotkey, and by hand, using the steps I described in comment 41.

comment:58 Changed 2 months ago by michael

So in other words (no need to answer if this is correct) where there was previously no "up" event at all there are now two. Needs looking at, but still a usability improvement!

comment:59 Changed 2 months ago by mhanor

There were some up events in the previous builds, but with key codes that seem unrelated to me, with regard to the actual key involved in the tests. If you look at the first screenshot (winxp.png), at the bottom of the keytool window, you can observe one up event, key code 194 (scan code 126). I don't understand why it's there. Keytool also recorded that the previous state was also "Up". In the 2nd screenshot (winxp2.png), you can observe the same key code with the same scan code and the same previous state.

Last edited 2 months ago by mhanor (previous) (diff)

Changed 2 months ago by mhanor

to reproduce on linux

comment:60 Changed 8 weeks ago by michael

Do you also see this with Linux guests? (I was so far unable to reproduce it.) And is it causing you problems, apart from being visible in Keytool?

comment:61 Changed 8 weeks ago by mhanor

It's not causing me problems, I have reported it in case it's something of interest. Do you know a keytool equivalent for Linux?

comment:62 Changed 8 weeks ago by michael

xev. It is a standard component of X11.

comment:63 Changed 8 weeks ago by mhanor

I have tested with Ubuntu as guest, and xev doesn't display the unrelated key-up event. It seems that X11 or the kernel filters the abnormal events, such as a key-up event without a corresponding previous key-down event. You can test it this way:

vboxmanage controlvm VMNAME keyboardputscancode a1
vboxmanage controlvm VMNAME keyboardputscancode 21 a1
vboxmanage controlvm VMNAME keyboardputscancode a1
Last edited 8 weeks ago by mhanor (previous) (diff)

comment:64 Changed 8 weeks ago by michael

I was able to find what was causing the problem, but I would need more time than I can justify just now to understand the code well enough to fix it properly. So I will have to leave this ticket open, but I hope that the major problem is fixed. I will update the test builds later today.

comment:65 Changed 3 weeks ago by rrt

Just to clarify, is the fix that you made available in test builds available in any subsequent release, or do I need to keep using the test build for now (which is fine!).

comment:66 Changed 3 weeks ago by michael

Yes, the problem should be fixed (the main problem, not Mihai's double release one) in the latest release. A confirmation would be great of course.

comment:67 Changed 3 weeks ago by mhanor

Yes, it's fixed.

comment:68 Changed 3 weeks ago by michael

  • Status changed from reopened to closed
  • Resolution set to fixed
  • Summary changed from Host key (ctrl) sometimes gets stuck down in Windows guest to Host key (ctrl) sometimes gets stuck down in Windows guest -> fixed in 4.3.24

Thanks for confirming. Since I don't see myself finding time to look at the minor issue, and I doubt anyone else feels strongly enough about it to submit a fix I will close this ticket.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use