Hello, AWT Team. Sorry for this mess with updates, please review the updated fix for the issue: http://bugs.sun.com/view_bug.do?bug_id=8005405 The new version is available at: http://cr.openjdk.java.net/~pchelko/8005405/webrev.02/
As Sergey noticed there was a bug in the previous version: the getParent method could return an owner of the window an coordinates would be computed incorrectly. In the updated version this issue is solved and the code is further simplified. Thank you. With best regards. Petr. On Jan 24, 2013, at 7:35 PM, Petr Pchelko wrote: > Hello, AWT Team. > > Please, review an updated fix for: > http://bugs.sun.com/view_bug.do?bug_id=8005405 > at > http://cr.openjdk.java.net/~pchelko/8005405/webrev.01/ > > Sergey suggested to simplify the loop which computes the component offset. I > simplified it and deleted the check that a peer is an instance of > LWComponentPeer because as I understand it is always true for a root > component in the hierarchy on the mac. > > The updated fix is tested on toy apps and on netbeans. > > With best regards, Petr. > > On Jan 23, 2013, at 6:35 PM, Petr Pchelko wrote: > >> Hello, AWT team. >> >> Please, review the fix for the issue >> http://bugs.sun.com/view_bug.do?bug_id=8005405 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/8005405/webrev.00/ >> >> 2 problem existed: >> 1. Calculation of the dragOrigin and componentOffset relied on the >> component.isLightweight() method, which considers all the AWT components >> heavyweight on Mac, however we really wanted there to find the component >> which has a real NSView or NSWindow under it. Replacing it with instanceof >> Window solves the problem. >> 2. On the native level the dragOrigin and location of the dragEvent >> were calculated without respect to the fact than Cocoa coordinate system is >> flipped. >> >> The fix is tested on toy apps with both AWT and Swing components. Also I >> have run netbeans on the JDK with this fix and all drag images look good. >> >> With best regards. Petr. >
