Can anyone tell me why pressing the tab key in a VNC session causes problems? When I press a tab key in a VNC session (including other viewers) I don’t get a tab, instead it’s as if I pressed Alt-Tab, I get a list of possible sessions to jump to, but for all intents and purposes, the session is toast. I have to quit the viewer and restart the session as I can never recover the keyboard.
Generally speaking you should be able to use the TAB key just fine in any VNC session. It works fine under normal circumstances.
The scenario you are describing sounds like the ALT key on the target machine is being held down. There are a number of things that can account for this:
[list]A VNC viewer could have it “stuck down” (Vine Server should release all keys when a client disconnects)
If it’s a MacOS X 10.4 machine then a different user on the machine could have it held down (Currently although 10.4 allows discrete user interfaces, the keyboard interpreter has a bug where all modifier keys are shared)
It could actually BE held down (locally and physically)[/list:u]
Sometimes if you press and release each ALT key (left and right) you can relieve the situation, other times might require the Server or even the whole machine be restarted, depending on the Server in question.
Thanks for the input. I do notice that if I minimize the window and then reexpand it, I can control the keyboard again. It happens across many clients and in Windows and OS X. Perhaps it’s a problem with the VNC server in Fedora.
I noticed something similar before we went on Thanksgiving break. I have never seen this before switching over to Vine.
I have a text field that is selected. I need to tab to the next field which will trigger an event. I have shouldRepositionMouse set to false. When I tab via typeText " " it tabs to the field then the mouse seems to move causing the even to change. I even changed the Eggplant options to turn off repositionMouse just incase I was missing something. I didn’t help.
I if the mouse moves after I tab to this field it will break the test.
Charles:
As far as Eggplant is concerned it sounds like you might be encountering the “wiggle mouse” behavior. This was added to compensate for some problems in MacOS X 10.3 and early 10.4 but appears to have largely gone away.
Try issuing the following commands in a script before the UI interaction and see if they help:
set the wiggleMouseAfterTyping to OFF
set the wiggleMouseAfterClick to OFF
Okay good news. This worked but I don’t understand it. A few questions.
Who’s bug is this?
Why isn’t this documented?
What is the bug here?
If this is a known issue why not always have this off?
Should I turn it back on?
Thanks,
Charles
If things are working for you, you probably don’t really need to understand it. 
However, since you asked, here are the gory details (more or less):
In earlier versions of Mac OS X (10.2 ? and 10.3, I believe, and also early releases of 10.4) there was an occasional problem with mouse clicks not being “noticed”. In some situations you could click the mouse on something, and if you clicked very carefully, without moving the mouse at all (which is actually very easy to do with a trackpad on a laptop, but somewhat hard to do with an actual mouse) the system wouldn’t respond to the click. You could sit there for minutes waiting for something to happen but it would be as if you had never clicked. But as soon as you began to move the mouse, the system would register the earlier click, and the click action would be performed.
This was clearly a bug in Mac OS X, and one which caused bad problems for some Eggplant scripts, since Eggplant would of course click and not move the mouse at all. We filed a bug report with Apple, and they eventually seem to have resolved the problem.
As a workaround while the bug was being fixed, and for anyone who still needs to test software running on the problematic versions of Mac OS X, we added a little “wiggle” in Eggplant, to make it act a little more human, you might say. Whenever an Eggplant script sends a click to the SUT, it also moves the mouse over a pixel and back again. This seems to be enough to get the system to recognize the click, and we added the same movement following typing.
Now you know what Eggplant is doing, and why. In case this mouse wiggling might turn out to be a problem, we decided to make it possible to disable this behavior, using the global properties that Jonathan mentioned above. But those properties were purposely NOT documented, for a couple of reasons. One is that this whole business is too confusing and requires far too much explanation (see above), and we want to keep Eggplant simple. Another is that this behavior may be changed or removed altogether in a future release, once the problem that it addresses no longer exists.
So, if you have a situation where the mouse must not move after clicking or typing, then please feel free to turn the mouse wiggle off. You might want to consider whether this represents a problem in your application, though, since humans have a tendency to wiggle their mouse a little, possibly even while they are typing with the other hand. So an application that behaves differently when tabbing to another field if the mouse moves one pixel may be confusing to users. Just a thought. 
Oh, and I don’t think any of this has anything to do with the tab key issue that was the original topic here. If anyone else has issues with the tab key in particular, or with modifier keys not being released in Vine, please let us know.
Thanks for taking the time to explain all of this. I know that required a bit of time on your part. I work on Flash Player and we are often testing strict sets of test on the product. For example we test various Tabbing functionallites which get disrupted by mouse movements. This is an old old bug in our product that doesn’t really affect the user but more or less us automaters. This is why is is a problem and I appreciate the fix. I was about to pull my hair out.
I assume there is no risk by turning this off as a default setting?
~Charles :roll:
I assume there is no risk by turning this off as a default setting?
Right. The only problem I know of would be if you run into the issue with non-responsiveness that the mouse wiggle was designed to fix.
You can also turn this off by default (so you don’t have to do it in all of your scripts) using the defaults system. In a terminal window, the command to do this is:
defaults write com.redstonesoftware.Eggplant wiggleMouseAfterTyping NO
I am testing Vine Viewer and when I connect to all three of my VNC servers on different machines whenever I type the tab key it is interpreted by the host as Command-Tab so up pops the application switching dialog. The server is Vine Server 2.1.
Note, if I run a session using Chicken of the VNC this tab behavior does NOT occur.
I am ready to purchase Vine Viewer as I like the scaling and built-in SSH option (though I hate the brushed metal…any way to set a default to use the unified theme?), but trying to use a computer when you can’t use a tab key is really annoying.
The servers are on 10.3.9 and 10.4.8 machines and my client is 10.4.8.
Hmm…let’s try to get to the bottom of this.
What keyboards are being used on the two machines?
Similiarly, how is the OS set as far as keyboard recognition?
If you could post a copy of your VNC log it might also contain some clues as to why this is happening.
Vine Viewer is running on a MacBook Core 2 Duo and the problem occurs when using either the built in keyboard (alone) or an external Matias OS X keyboard. My keyboard setting is normally Dvorak US but even changing it to standard U.S. did not solve the problem.
The Servers are running on a MacBook Core Duo with built in keyboard (U.S. setting), iBook G4 with external Apple USB Keyboard (U.S. setting) and Blue and White with Logitech USB Keyboard (U.S. setting).
Symptom occurs on all three servers. Note, all three servers are running in Startup System Server mode. They also are only accepting local connections so running via ssh.
Additional info. The problem also manifests itself in another way, I just realized. If I hit the Tab key, the Server acts as if I held down the Command Key as previously noted. If I hit escape to back out of the application switch mode, the Server still seems to think my command key is held down. Thus, if I try and click on an application in the dock to switch to it, it instead opens the application file in the Finder (which is what happens when you command click on a Dock icon).
I can turn that behavior off by hitting the command key twice on my Vine Viewer client so that I leave and then reenter live mode.
I tried getting the Vine Server log off the Server computer but it only gave me a log from when I booted Vine Server from the Finder. Where is the log if it runs in Startup System Server mode?
Try switching the Live Mode Toggle Key to something other than Command (from Preferences -> Viewer Window). See if that makes a difference in the behavior you are seeing. Also, do you see this behavior when you first connect to the server, before any other actions have been taken?
Good thought but, alas, the problem continued even when I changed the default to control.
And, yes, this action begins immediately upon the connection being established.
The log for the System Server can be found in /var/log/osxvnc
Are your servers also running Dvorak? If not is there something else common to the three servers that is a little non-standard?
[quote=“JonathanOSX”]The log for the System Server can be found in /var/log/osxvnc
Are your servers also running Dvorak? If not is there something else common to the three servers that is a little non-standard?[/quote]
Nope, as mentioned above only my client is Dvorak and the problem occurs even if I switch to the US layout.
I’ll get the log.
2006-12-19 08:48:07 /Library/StartupItems/OSXvnc/OSXvnc-keepalive: Starting
2006-12-19 08:48:07 pwd: ‘/’
2006-12-19 08:48:07 id: ‘uid=0(root) gid=0(wheel) groups=0(wheel)’
2006-12-19 08:48:07 uname -a: ‘Darwin JanetNimbus.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386’
2006-12-19 08:48:07 uptime: ’ 8:48 up 19 secs, 0 users, load averages: 0.07 0.02 0.00’
2006-12-19 08:48:07 /Library/StartupItems/OSXvnc/OSXvnc-keepalive: Starting Server ‘/Library/StartupItems/OSXvnc/OSXvnc-server’
2006-12-19 08:48:07.582 OSXvnc-server[154] Arguments: -rfbport 5904 -desktop JanetNimbus -dontdisconnect -restartonuserswitch Y -keyboardLoading N -pressModsForKeys N -swapButtons -localhost -rendezvous N
2006-12-19 08:48:07.582 OSXvnc-server[154] Note: No password file specified, running with no authentication
2006-12-19 08:48:07.595 OSXvnc-server[154] Main Bundle: /Library/StartupItems/OSXvnc
2006-12-19 08:48:07.597 OSXvnc-server[154] Loading Bundle /Library/StartupItems/OSXvnc/Resources/JaguarBundle.bundle
2006-12-19 08:48:07.652 OSXvnc-server[154] Keyboard Loading - Disabled
2006-12-19 08:48:07.652 OSXvnc-server[154] Press Modifiers For Character - Disabled
2006-12-19 08:48:07.688 OSXvnc-server[154] Running in Little Endian
2006-12-19 08:48:07.689 OSXvnc-server[154] Pasteboard Inaccessible - Pasteboard sharing disabled
2006-12-19 08:48:07.720 OSXvnc-server[154] Rendezvous(_rfb._tcp) - Disabled
2006-12-19 08:48:07.720 OSXvnc-server[154] Rendezvous(_vnc._tcp) - Disabled
2006-12-19 08:48:07.720 OSXvnc-server[154] Waiting for clients
2006-12-19 08:48:07.721 OSXvnc-server[154] IPv6: Started Listener Thread on port 5904
2006-12-19 08:48:07.722 OSXvnc-server[154] Started Listener Thread on port 5904
2006-12-19 09:24:08.440 OSXvnc-server[154] rfbProcessClientProtocolVersion: client gone
2006-12-19 09:24:08.440 OSXvnc-server[154] Client 127.0.0.1 disconnected
2006-12-19 09:24:08.440 OSXvnc-server[154] Statistics:
2006-12-19 09:24:08.440 OSXvnc-server[154] framebuffer updates 0, rectangles 0, bytes 0
2006-12-19 09:24:08.440 OSXvnc-server[154] Client gone
2006-12-19 09:24:08.478 OSXvnc-server[154] Waiting for clients
2006-12-19 10:33:30.130 OSXvnc-server[154] rfbProcessClientProtocolVersion: client gone
2006-12-19 10:33:30.130 OSXvnc-server[154] Client 127.0.0.1 disconnected
2006-12-19 10:33:30.130 OSXvnc-server[154] Statistics:
2006-12-19 10:33:30.130 OSXvnc-server[154] framebuffer updates 0, rectangles 0, bytes 0
2006-12-19 10:33:30.130 OSXvnc-server[154] Client gone
2006-12-19 10:33:30.152 OSXvnc-server[154] Waiting for clients
2006-12-19 10:38:47.120 OSXvnc-server[154] Protocol version 3.3
2006-12-19 10:38:47.120 OSXvnc-server[154] Ignoring minor version mismatch
2006-12-19 10:38:47.170 OSXvnc-server[154] Pixel format for client 127.0.0.1:
2006-12-19 10:38:47.170 OSXvnc-server[154] 32 bpp, depth 24, big endian
2006-12-19 10:38:47.170 OSXvnc-server[154] true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
2006-12-19 10:38:47.170 OSXvnc-server[154] ENCODING: ZlibHextile for client 127.0.0.1
2006-12-19 10:38:47.170 OSXvnc-server[154] Enabling Immediate updates for client 127.0.0.1
2006-12-19 10:38:47.170 OSXvnc-server[154] Enabling Cursor Shape protocol extension for client 127.0.0.1
2006-12-19 10:38:47.170 OSXvnc-server[154] Enabling Cursor Position protocol extension for client 127.0.0.1
2006-12-19 10:38:47.193 OSXvnc-server[154] Client Connected - Registering Screen Update Notification
2006-12-19 10:39:20.690 OSXvnc-server[154] Client 127.0.0.1 disconnected
2006-12-19 10:39:20.690 OSXvnc-server[154] Statistics:
2006-12-19 10:39:20.690 OSXvnc-server[154] key events received 10, pointer events 169
2006-12-19 10:39:20.690 OSXvnc-server[154] framebuffer updates 639, rectangles 1578, bytes 4785923
2006-12-19 10:39:20.690 OSXvnc-server[154] ZlibHextile rectangles 1575, bytes 4782455
2006-12-19 10:39:20.690 OSXvnc-server[154] Cursor Shape Updates rectangles 2, bytes 3456
2006-12-19 10:39:20.690 OSXvnc-server[154] Cursor Position Updates rectangles 1, bytes 12
2006-12-19 10:39:20.690 OSXvnc-server[154] raw bytes equivalent 24064272, compression ratio 5.028136
2006-12-19 10:39:20.690 OSXvnc-server[154] Client gone
2006-12-19 10:39:20.721 OSXvnc-server[154] UnRegistering Screen Update Notification - waiting for clients
Just a followup. I wondered if you had any thoughts on the tab issue.
After your suggestion on how to use the GUI Server version with the Startup Server I’ve tried tabbing when using both Server versions and ports and it still exists.
I also thought that it might be helpful if you have a “test” Vine Server platform that I could pop into and your folks could watch/log the interaction.
Right now it’s still a mystery. You said that it doesn’t happen with Chicken so it must be something on the client side but really we just send a tab key exactly the way it would be expected.
AHA, I figured it out!!!
I use TypeIt4Me (a utility like TextExpander which expands shortcuts, aka “vs” to Vine Server). When I turn that off the weird behavior is gone.
For whatever reason, Vine Viewer and TypeIt4Me have an issue whereas Chicken of the VNC does not.