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

[Leonid Romanov]

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.     

On 23.12.2011, at 16:13, Artem Ananiev wrote:

> 
> On 12/22/2011 10:10 PM, Leonid Romanov wrote:
>> 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
> 
>> The webrev is located at:
>> http://cr.openjdk.java.net/~leonidr/event-number/
>> 
>> Thanks,
>> Leonid.
>> 
>>