Review request for MACOSX_PORT-651: Modal behavior difference with and without Robot interaction

Discussion:

Leonid Romanov

2011-12-22 18:10:46 UTC

Hello!
Please review the fix for http://java.net/jira/browse/MACOSX_PORT-651
I'm not really satisfied with the fix (you will understand why when you see it), so it would be great if Apple guys could take a look at it.

The webrev is located at:
http://cr.openjdk.java.net/~leonidr/event-number/

Thanks,
Leonid.

Artem Ananiev

2011-12-23 12:13:33 UTC

Permalink

Post by Leonid Romanov
Hello!
Please review the fix for http://java.net/jira/browse/MACOSX_PORT-651
I'm not really satisfied with the fix (you will understand why when you see it), so it would be great if Apple guys could take a look at it.

Yes, the fix looks mysterious: it is not clear at all, why setting
kCGMouseEventNumber eliminates the problem. Is there any specification
for this flag?

Thanks,

Artem

Post by Leonid Romanov
http://cr.openjdk.java.net/~leonidr/event-number/
Thanks,
Leonid.

Leonid Romanov

2011-12-23 13:06:12 UTC

Permalink

Well, first of all, check this thread:
http://lists.apple.com/archives/quartz-dev/2010/May/msg00050.html

This is where I've learned about the importance of event numbers. Apple docs don't say much about it other than it is used for matching mouse-down and mouse-up events

I've also done some experiments, like replacing -eventNumber method with a method that always return 0.
With that change I was able to reproduce the bug manually, without Robot involvement. This had given me a confirmation that I was on the right track. Being a curios person, I spent some time with gdb, trying to find out what's going on. Here is what I've found: it all starts with _NXDoDeferredWindowOrdering SPI function that gets called on the app side as result of pressing mouse button. It takes the event's number and time stamp among other parameters and, after doing some work, makes a RPC call to the window server's CGXDoDeferredOrdering function with the event's number as one of the parameters.
So, all the evidences are that the event number is somehow involved in determining windows order. I haven't traced it further because it requires remote debugging and I wasn't in the mood for it.

Yes, the fix looks mysterious: it is not clear at all, why setting kCGMouseEventNumber eliminates the problem. Is there any specification for this flag?
Thanks,
Artem

Post by Leonid Romanov
http://cr.openjdk.java.net/~leonidr/event-number/
Thanks,
Leonid.

Anthony Petrov

2011-12-23 12:22:35 UTC

Permalink

Hi Leonid,

I'm not an Apple guy, but I'll chime in anyway. Firstly, the Internets
suggest that your fix is okay [1]. BTW, I'd suggest to initialize the
static variables that you put into blocks, since you assign values to
them conditionally, but use them in any case. I realize that normally a
MouseUP doesn't come before a MouseDown, but just in case... After all
it's a user who calls Robot methods.

However, FWIW, have you tried using a different event tap
(kCGHIDEventTap instead of kCGSessionEventTap) to post events w/o
dealing with the event numbers? We use kCGHIDEventTap in another
project, and I don't recall any issues requiring us to set the event
numbers for synthetic mouse events explicitly. Perhaps we don't use this
piece of code too very often to encounter the issue though, but still
this idea is worth giving it a try, isn't it?

[1]
http://stackoverflow.com/questions/2602224/synthetic-click-doesnt-switch-applications-menu-bar-mac-os-x

--
best regards,
Anthony

Leonid Romanov

2011-12-23 13:10:38 UTC

Permalink

Hi!
Yep, I'll definitely try using kCGHIDEventTap instead of kCGSessionEventTap, thanks!

Leonid.

Post by Anthony Petrov
Hi Leonid,
I'm not an Apple guy, but I'll chime in anyway. Firstly, the Internets suggest that your fix is okay [1]. BTW, I'd suggest to initialize the static variables that you put into blocks, since you assign values to them conditionally, but use them in any case. I realize that normally a MouseUP doesn't come before a MouseDown, but just in case... After all it's a user who calls Robot methods.
However, FWIW, have you tried using a different event tap (kCGHIDEventTap instead of kCGSessionEventTap) to post events w/o dealing with the event numbers? We use kCGHIDEventTap in another project, and I don't recall any issues requiring us to set the event numbers for synthetic mouse events explicitly. Perhaps we don't use this piece of code too very often to encounter the issue though, but still this idea is worth giving it a try, isn't it?
[1] http://stackoverflow.com/questions/2602224/synthetic-click-doesnt-switch-applications-menu-bar-mac-os-x
--
best regards,
Anthony

Leonid Romanov

2011-12-29 16:26:04 UTC

Permalink

Hi,
I've tried your suggestion and it didn't make any difference.
Here is updated webrev:
http://cr.openjdk.java.net/~leonidr/7124289/webrev.00/

Leonid.

Anthony Petrov

2011-12-30 10:36:24 UTC

Permalink

Hi Leonid,

Well, OK then. The current fix looks fine.

--
best regards,
Anthony

Post by Leonid Romanov
Hi,
I've tried your suggestion and it didn't make any difference.
http://cr.openjdk.java.net/~leonidr/7124289/webrev.00/
Leonid.