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

On 11/29/2016 8:11 PM, Sergey Bylokhov wrote: 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.

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? A

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 poste

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 can

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 itsel

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 du

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 mea

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 norm

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

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.

[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 suppor

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 w

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 c

[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] 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() meth

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