Re: [9] fix for JDK-8134612 :clipboard.getData(dataFlavor) can throw UnsupportedFlavorException for registered data flavor

The fix looks good to me. The 8133719 could be also added to the test @bug tag. Thanks, Alexandr. On 11/28/2016 3:20 PM, Ajit Ghaisas wrote: Thanks Alex for the review comments. As suggested, I have updated the test which results in the call to DataTransferer.constructFlavoredObject()

Re: [9] Review request for 8169589: [macosx] Activating a JDialog puts to back another dialog

Hi Sergey, You are right. The methods orderAboveSiblings() and orderAboveSibligsImpl() are executed on the appkit thread. I have updated the fix. Now these functions invoke getOwnedWindows_NoClientCode() via window accessor instead of direct call of getOwnedWindows from the Window class. The

[9] Review request for JDK-8160536: [macosx] Possible regression: com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java

Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8160536 Webrev: http://cr.openjdk.java.net/~mhalder/8160536/webrev.00/ Issue: Menubar event was

Re: [9] Review request for 8166683: On macOS (Mac OS X) getting a ScreenMenuBar when not running "com.apple.laf.AquaLookAndFeel"

I don't find any modern jdk9 prefix convention for such property, so I've named it "jdk.swing.disableForcedGlobalMenuBar" http://cr.openjdk.java.net/~azvegint/jdk/9/8166683/02/ Thanks, Alexander. On 11/28/16 9:05 PM, Sergey Bylokhov wrote: Looks fine, but here is some of my thoughts: Since

Re: [9] Review request for 8169589: [macosx] Activating a JDialog puts to back another dialog

Looks fine. On 29.11.16 12:10, dmitry markov wrote: Hi Sergey, You are right. The methods orderAboveSiblings() and orderAboveSibligsImpl() are executed on the appkit thread. I have updated the fix. Now these functions invoke getOwnedWindows_NoClientCode() via window accessor instead of direct

Re: [9] Review request for 8165705: Robot.createScreenCapture produces black screenshot on Oracle Linux 7.1

On 29.11.16 17:39, Semyon Sadetsky wrote: On 11/28/2016 11:03 PM, Sergey Bylokhov wrote: On 24.11.16 22:24, Semyon Sadetsky wrote: Having an extra unspecified functionality on which application can depends is not better, it is also slower, and during evaluation of bugs it will be necessary to

[9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8170386 webrev: http://cr.openjdk.java.net/~ssadetsky/8170386/webrev.00/ Paint event may be missed by the JLightweightFrame on Windows platform when it is resized consequently to the same size because the latter

Re: [9] Review request for JDK-8160536: [macosx] Possible regression: com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java

Looks fine. On 29.11.16 14:10, Manajit Halder wrote: Hi All, Kindly review the fix for JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8160536 Webrev: http://cr.openjdk.java.net/~mhalder/8160536/webrev.00/ Issue: Menubar event was not handled in case of key down events Fix: Added

Re: [9] Review request for 8169133: This time, on Windows: java/awt/Robot/SpuriousMouseEvents/SpuriousMouseEvents.java

On 11/28/2016 11:13 PM, Sergey Bylokhov wrote: On 25.11.16 17:08, Semyon Sadetsky wrote: Then JDK-8013116 was fixed the request for specification update was created: https://bugs.openjdk.java.net/browse/JDK-8033128 Different coordinate system simply means different coordinate origins. This is

Re: [9] Review request for 8165705: Robot.createScreenCapture produces black screenshot on Oracle Linux 7.1

On 11/28/2016 11:03 PM, Sergey Bylokhov wrote: On 24.11.16 22:24, Semyon Sadetsky wrote: Having an extra unspecified functionality on which application can depends is not better, it is also slower, and during evaluation of bugs it will be necessary to know that this can be switched at runtime.

Re: [9] Review request for 8169133: This time, on Windows: java/awt/Robot/SpuriousMouseEvents/SpuriousMouseEvents.java

On 29.11.16 17:47, Semyon Sadetsky wrote: If the same coordinate system is shared by both screens, means that each point passed to the robot will be related to the(0,0). It is not necessary the (left/top) point of the screen because the screen itself can be shifted from the (0,0)/ That would

Re: [9] Review request for 8165705: Robot.createScreenCapture produces black screenshot on Oracle Linux 7.1

On 11/29/2016 5:52 PM, Sergey Bylokhov wrote: On 29.11.16 17:39, Semyon Sadetsky wrote: On 11/28/2016 11:03 PM, Sergey Bylokhov wrote: On 24.11.16 22:24, Semyon Sadetsky wrote: Having an extra unspecified functionality on which application can depends is not better, it is also slower, and

Re: [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

On 29.11.16 17:35, Semyon Sadetsky wrote: Paint event may be missed by the JLightweightFrame on Windows platform when it is resized consequently to the same size because the latter sets paintPainding flag . From what place the Paint will be posted after the call to setBounds()? In case of

Re: [9] Review request for 8169133: This time, on Windows: java/awt/Robot/SpuriousMouseEvents/SpuriousMouseEvents.java

On 11/29/2016 6:09 PM, Sergey Bylokhov wrote: On 29.11.16 17:47, Semyon Sadetsky wrote: If the same coordinate system is shared by both screens, means that each point passed to the robot will be related to the(0,0). It is not necessary the (left/top) point of the screen because the screen

Re: [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

On 11/29/2016 6:24 PM, Sergey Bylokhov wrote: On 29.11.16 17:35, Semyon Sadetsky wrote: Paint event may be missed by the JLightweightFrame on Windows platform when it is resized consequently to the same size because the latter sets paintPainding flag . From what place the Paint will be

Re: [9] Review request for 8169133: This time, on Windows: java/awt/Robot/SpuriousMouseEvents/SpuriousMouseEvents.java

On 29.11.16 19:18, Semyon Sadetsky wrote: On 29.11.16 17:47, Semyon Sadetsky wrote: If the same coordinate system is shared by both screens, means that each point passed to the robot will be related to the(0,0). It is not necessary the (left/top) point of the screen because the screen itself

Re: [9] Review request for 8170386: JLightweightFrame content can miss paint events on Windows

On 29.11.16 20:00, Semyon Sadetsky wrote: From what place the Paint will be posted after the call to setBounds()? In case of normal native components this event will be posted from native code after the size of the native component will be changed. But how it works in case of JLightweightFrame?