Community
Participate
Working Groups
Display.post does not work as expected with cocoa/64 running on OSX 10.6. This used to work fine until I upgraded from carbon on OSX 10.5. This is a complete blocker for swtbot to work on cocoa since most keyboard inputs work anymore. Here's the details on my platform: SWT Version: 3650 SWT Platform: cocoa Operating System: Mac OS X/x86_64 OS Version 10.6.4 Attached testcase tries to post the following events to the display using display.post: * press/release SWT.ALT * press/release SWT.SHIFT * press/release SWT.CTRL * press/release SWT.COMMAND * press/release SWT.ARROW_UP * press/release SWT.ARROW_DOWN However none of the modifier keys seem to be sent to the widget. The other arrow keys work fine.
Created attachment 182448 [details] A simple program to demonstrate the bug
Fixed in HEAD > 20101108. I'm using CGEventCreateKeyboardEvent instead of CGPostKeyboardEvent, which works on 10.6 but I seem to recall there were problems on 10.5. I'll verify; hopefully we won't need conditional code.
Looks okay on 10.5 as well.
Thanks a lot! Reading the apple docs mentioned that this api was CGPostKeyboardEvent was deprecated. I also happened to read that CGPostMouseEvent is deprecated in 10.6. Would this be an issue with mouse events too ? http://developer.apple.com/library/mac/#documentation/Carbon/Reference/QuartzEventServicesRef/DeprecationAppendix/AppendixADeprecatedAPI.html%23//apple_ref/c/func/CGPostMouseEvent
(In reply to comment #4) > Thanks a lot! Reading the apple docs mentioned that this api was > CGPostKeyboardEvent was deprecated. > > I also happened to read that CGPostMouseEvent is deprecated in 10.6. Would this > be an issue with mouse events too ? > Yes, I have seen that. Your comment prodded me to try out a snippet to see what happens if multiple buttons were pressed, and the result was not good. You end up in a state where one button thinks it is still down, and CG becomes very confused at that point. As written, the code looks like it supports the ability to add in the current state of the mouse when Display.post() is called. Carbon & Cocoa are the only platforms where this is done. I really can't see a good reason to do that just on the Mac, so I'll look into changing it.
(In reply to comment #5) > Yes, I have seen that. Your comment prodded me to try out a snippet to see what > happens if multiple buttons were pressed, and the result was not good. You end > up in a state where one button thinks it is still down, and CG becomes very > confused at that point. Turns out that I broke a snippet with the last checkin, but with some research I found that we need to create a CGEventSourceRef and use that when creating events. I rewrote the mouse and mousewheel handling code to use the newer CGEventCreateXXXEvent calls, which should make key and mouse events much more reliable now. Fixed (again) > 20101108.
A follow-up fix for this was checked in 2010-11-10 at 10:45 PST. I'll attach the test case I used to verify it.
Created attachment 183015 [details] test case This is a SWT-only version of the UI keys test that is failing in the nightly builds.
The JUnit Bug43610Test still fails. For me the "test case" works fine, but the JUnit run in Eclipse (Bug43610Test) fails. The JUnit gets event (SWT.KeyDown, SWT.Shift). This might be a timing issue. On my Mac when JUnits are run on a clean workspace, Eclipse has "Welcome" screen up and the following entries in the stack: WebKit.browserProc WebKit.handleEvent If I close the "Welcome" screen before JUnit is allowed to run, then the JUnit passes on my computer. However, the stack trace from the build machine does not have WebKit entries in it, which suggests that cause of the problem is not the browser itself, but rather a timing issue of some sort. With this in mind, it does seem that the fix introduced intermittent problem on 32 bit Cocoa. > I'm using CGEventCreateKeyboardEvent instead of CGPostKeyboardEvent, which > works on 10.6 but I seem to recall there were problems on 10.5. > I'll verify; hopefully we won't need conditional code.
(In reply to comment #9) > This might be a timing issue. On my Mac when JUnits are run on a clean > workspace, Eclipse has "Welcome" screen up and the following entries in the > stack: > WebKit.browserProc > WebKit.handleEvent > > If I close the "Welcome" screen before JUnit is allowed to run, then the JUnit > passes on my computer. > > However, the stack trace from the build machine does not have WebKit entries in > it, which suggests that cause of the problem is not the browser itself, but > rather a timing issue of some sort. To try to address this I added a 1 millisecond sleep before posting each event. This will ensure that each event gets its own timestamp and then they can't be processed out of order. I'm running the UITestSuite on my 10.5 machine to see how things are working there.
UITestSuite ran to completion with no errors in the key events, so I'm marking this as fixed. Hopefully we'll have a successful run tonight.
*** Bug 330427 has been marked as a duplicate of this bug. ***
The JUnits still fail on recent builds, including I20101116-0800 and N20101116-2000. Could you please revert the change until the reasons for JUnit failures are cleared?
(In reply to comment #13) > The JUnits still fail on recent builds, including I20101116-0800 and > N20101116-2000. > > Could you please revert the change until the reasons for JUnit failures are > cleared? I'll make the code conditional, as the old code did nothing on 10.5. At the very least it won't cause errors anymore.
This is now 'fixed' but only because CGPostKeyboardEvent is apparently completely broken on OS X 10.5 for modifier keys. The original fix will continue to work on 10.6.
