United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7124289 [macosx] Modal behavior difference with and without Robot interaction
JDK-7124289 : [macosx] Modal behavior difference with and without Robot interaction

Details
Type:
Bug
Submit Date:
2011-12-23
Status:
Closed
Updated Date:
2012-09-25
Project Name:
JDK
Resolved Date:
2012-02-28
Component:
client-libs
OS:
os_x
Sub-Component:
java.awt
CPU:
generic
Priority:
P2
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
7u4 (b11)

Related Reports
Relates:

Sub Tasks

Description
http://java.net/jira/browse/MACOSX_PORT-651 submitted 2011/11/03 by Yuri Nesterenko
Run the attached test adapted from a real one. There are three Frames and a Dialog. First, just look how robot clicks here and there. For me, both F2 and F3 frames consistently overlap the (modal) Dialog, so that's a bug and broken behavior, right? Now, when robot finished, try to click by hand on decorations and visible space in the frames: you will never get the same results – everything will works as designed.
It's bizarre. What is broken here?

                                    

Comments
EVALUATION

Author: Yuri Nesterenko Date: 03/Nov/11 08:56 AM
Build: b215
closed/java/awt/Modal/ZOrderTest6271792/ZOrderTest.java
 
Author: Artem Ananiev Date: 07/Nov/11 04:25 PM
Raising priority to critical as it likely affects all the automatic modality tests.
 
Author: Leonid Romanov Date: 19/Dec/11 05:40 PM
There is an event number associated with every NSEvent. For real events, the numbering starts at some value close to zero and gets incremented on each button press. Apparently, the window server uses event numbers to determine windows z-order. One might expect that Apple API for synthesizing mouse events takes care of all that numbering stuff and assigns correct event numbers automatically, but it is not the case: you have to explicitly set the event number, otherwise it will be zero.
And this is why the test fail: because of the zero event numbers. They somehow confuse the window server.
The fix seems to be clear: set correct event numbers for the generated events. However, Apple docs are completely silent about the importance of event numbers and don't provide any guidance on how they should be generated.  Also, there is no API for obtaining current event number. It seems, though, that event numbers for the generated events must be higher than the event number for the last real mouse event. So, the solution suggested by Internet is to start numbering at some arbitrary number that is high enough, like 40000 or something. Although it doesn't guarantee for sure that generated events will have event numbers higher than real events, it should work in the most cases.
                                     
2011-12-23



Hardware and Software, Engineered to Work Together