Re: [9] Review request for 8177919: java.awt.Desktop.setDefaultMenuBar​() should be specified to throw IllegalStateException

+1 --Semyon On 04/11/2017 09:53 AM, Sergey Bylokhov wrote: Looks fine. Hello, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8177919/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8177919 This fix removes throwing of ISE, this allows to use default menu bar

Re: [9] Review Request: 8177841 Some java/awt/Robot tests can be improved

On 04/11/2017 09:06 AM, Sergey Bylokhov wrote: Anyway 2 minutes seems a very unusual waiting time for the event at any circumstances. Usually, in the client-libs tests after an action is triggered, we wait for silence in all event queues plus a small period of several hundreds milliseconds.

Re: [9] Review request for 8142540: [TEST_BUG] Test sun/awt/dnd/8024061/bug8024061.java fails on ubuntu

On 04/10/2017 09:34 PM, Sergey Bylokhov wrote: webrev: http://cr.openjdk.java.net/~ssadetsky/8142540/webrev.00/ Starting Ubuntu 15 windows got zero width borders. Initial mouse click point missed the panel to drag. Probably it will be better to use locations of panel1 and panel2 as an «here»

[10] Review request for 8132299: Test java/awt/Robot/ModifierRobotKey/ModifierRobotKeyTest.java fails on Linux

Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8132299 webrev: http://cr.openjdk.java.net/~ssadetsky/8132299/webrev.00/ The issue itself is a linux/solaris specific. Alt-Gr modifier bit (1<<5) is not set in the KeyPress event which is sent by the closing key

[9] Review request for 8178905: Undercorated frame is not painted on OEL7(Gnome3).

Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8178905 webrev: http://cr.openjdk.java.net/~ssadetsky/8178905/webrev.00/ When an undecorated window is initialized Gnome3 WM does not send the ConfigureNotify event which is must in the Linux AWT implementation t

Re: [9] Review request for 8178905: Undercorated frame is not painted on OEL7(Gnome3).

: 42 if(parentFrame.isTargetUndecorated() && "if(" -> "if (". Also use corrected spelling when for the synopsis in the commit. -phil. On 04/18/2017 09:12 AM, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.

[9] Review request for 8081454: [TESTBUG]Some java/awt/Mixing tests fail in OEL 7 only

Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8081454 webrev: http://cr.openjdk.java.net/~ssadetsky/8081454/webrev.00/ A number test of issues specific for OEL 7 is fixed. Some of them are synchronization issues, some are related to different size of frame

Re: [9] Review request for 8081454: [TESTBUG]Some java/awt/Mixing tests fail in OEL 7 only

dumb delay after invokeAndWait? loc2 and loc may be not ready on the main thread. Perhaps making them volatile could help here? Thanks, -yan On 04/18/2017 10:07 PM, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8081454 webrev:

Re: [9] Review request for 8178905: Undercorated frame is not painted on OEL7(Gnome3).

Actually, a lot of SQE test falls on OEL7 because of this bug. For example, the one which is linked to the JIRA issue. As it is pointed in JIRA the bug is reproducible in JDK8. Frame.isUndecorated() is not called here because the peer field is used. --Semyon On 04/19/2017 06:53 AM, Sergey Bylok

Re: [9] Review Request: 8178971 Uncommon formatting and typos in java.desktop module

On 04/19/2017 10:29 AM, Sergey Bylokhov wrote: Hello, Please review the fix for jdk9. Bug: https://bugs.openjdk.java.net/browse/JDK-8178971 Webrev can be found at: http://cr.openjdk.java.net/~serb/8178971/webrev.00 Webrev which ignores sp

Re: [9] Review Request: 8178971 Uncommon formatting and typos in java.desktop module

On 04/19/2017 12:43 PM, Sergey Bylokhov wrote: Same issues can be found in so many classes of java.desktop grep -rE "\\S+\\s{2,}=|\\S+=\\s{2,}\S+|^\\s{5,5}(public|private|static|final|void)" --include \*.java jdk/src/java.desktop | wc -l 2685 !!! Why you decided to fix only those several?

Re: [9] Review request for 8178905: Undercorated frame is not painted on OEL7(Gnome3).

On 04/19/2017 12:45 PM, Sergey Bylokhov wrote: Actually, a lot of SQE test falls on OEL7 because of this bug. For example, the one which is linked to the JIRA issue. As it is pointed in JIRA the bug is reproducible in JDK8. Then it is strange that those bugs from sqe was not reported on jdk8.

Re: [9] Review Request: 8178971 Uncommon formatting and typos in java.desktop module

On 04/19/2017 02:23 PM, Sergey Bylokhov wrote: In this grep output I see absolutely the same 5 spaces indentation instead of 4 spaces, multiple spaces around "=". The source of those formatting issues maybe the same (replacing tabs by spaces). And I did not get why the source is important? It

Re: [9] Review Request: 8178971 Uncommon formatting and typos in java.desktop module

On 04/19/2017 03:32 PM, Sergey Bylokhov wrote: Its is unimportant because most of them are not in the public API, some of them are aligned intentionally, but if you will find something useful feel free to file it file it and fix. I see a lot of such formatting issues (hundreds) in public APIs.

Re: [9] Review request for 8159451: [TEST_BUG] java/awt/Mixing/AWT_Mixing/JMenuBarOverlapping.java

/2017 12:21 AM, Phil Race wrote: No objection per se, but thinking aloud .. The default jtreg timeout is 2 minutes .. you are upping to 4 minutes. Can the test be made more efficient, or is that a realistic time based on what it tests ? -phil. On 04/05/2017 11:25 AM, Semyon Sadetsky wrote:

[9] Review request for 8160530: [TEST-BUG] Consistent failure of java/awt/dnd/MissingEventsOnModalDialog/MissingEventsOnModalDialogTest.java

Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8160530 webrev: http://cr.openjdk.java.net/~ssadetsky/8160530/webrev.00/ To issues are being fixed. The first, Delay was increased for the test stability on various platforms. The second, getting true from Dialo

[9] Review request for 8159904: [TEST_BUG] Failure on solaris of java/awt/Window/MultiWindowApp/MultiWindowAppTest.java

Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8159904 webrev: http://cr.openjdk.java.net/~ssadetsky/8159904/webrev.00/ Solaris platform was added to the test exclusions because Solaris WM do not permit to bring a window on top programmatically. --Semyon

Re: RFR: 8179365 : JAWT (AWT Native Interface) specification needs to be updated for JDK 9

+1 --Semyon On 04/26/2017 11:43 AM, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8179365 webrev: http://cr.openjdk.java.net/~prr/8179365/ the JAWT spec as currently published has not been maintained http://docs.oracle.com/javase/8/docs/technotes/guides/awt/AWT_Native_Interfa

Re: [9] Review request for 8159904: [TEST_BUG] Failure on solaris of java/awt/Window/MultiWindowApp/MultiWindowAppTest.java

Phil, this is a jdk9 issue found on Solaris 11.3. But jdk8 should not be very different. Much appreciate it if you will be able to run java/awt/Window/MultiWindowApp/MultiWindowAppTest.java on Solaris 10. But I'm not sure about Solaris 10 WM Gnome version. Its behavior can be different.

Re: [9] Review request for 8159904: [TEST_BUG] Failure on solaris of java/awt/Window/MultiWindowApp/MultiWindowAppTest.java

r "a datapoint". Also there are people in the Solaris org. we can ask .. -phil. On 4/28/17, 3:50 PM, Semyon Sadetsky wrote: Phil, this is a jdk9 issue found on Solaris 11.3. But jdk8 should not be very different. Much appreciate it if you will be able to run java/awt/Window/

[10] Review request for 8179665: [Windows] java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location

Hello, Please review fix for JDK10: bug: https://bugs.openjdk.java.net/browse/JDK-8179665 webrev: http://cr.openjdk.java.net/~ssadetsky/8179665/webrev.00/ The root cause of the issue is IME events are sent when always-on-top state is set or cleared even during the window is not visible. In th

Re: [9] Review request for 8178996 [macos] JComboBox doesn't display popup in mixed JavaFX Swing Application on 8u131 and Mac OS 10.12

Looks good. --Semyon On 05/11/2017 01:54 AM, Alexander Zvegintsev wrote: Hi all, please review the fix http://cr.openjdk.java.net/~azvegint/jdk/9/8178996/00/ for the issue https://bugs.openjdk.java.net/browse/JDK-8178996 Popup doesn't show up due to owner is lightweight frame and doesn't

Re: [10] Review request for 8179665: [Windows] java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location

Hi Sergey, The probability of such scenario is very low but I agree it doesn't equal to zero. Also, there is yet another scenario: right after the request to open candidate window is scheduled in the native queue the parent window is closed. The updated fix: http://cr.openjdk.java.net/~ss

[9] Review request for 8179665: [Windows] java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location

Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8179665 webrev: http://cr.openjdk.java.net/~ssadetsky/8179665/webrev.01/ The root cause of the issue is IME events are sent when always-on-top state is set or cleared even during the window is not visible. In thi

Re: [9] Review request for 8179665: [Windows] java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location

The correct link to webrev: http://cr.openjdk.java.net/~ssadetsky/8179665/webrev.01/ Sorry... On 05/18/2017 10:31 AM, Semyon Sadetsky wrote: Hello, Please review fix for JDK9: bug: https://bugs.openjdk.java.net/browse/JDK-8179665 webrev: http://cr.openjdk.java.net/~ssadetsky/8179665

Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

Hi, Are you sure that keyPress/keyRelease should emulate UTF8 symbols? Physical keyboard cannot produces so many keycodes with a single press/release. --Semyon On 08/22/2017 01:57 AM, Shashidhara Veerabhadraiah wrote: Hi All, Please review fix for the /_enhancement_/ wherein the robot ke

Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

Unicode keyboard events? Here the platform api offers to accept decimal values or code values as input though a real keyboard may not be able to generate the same and converts it into a displayable Unicode char. Thanks and regards, shashi *From:*Semyon Sadetsky *Sent:* Tuesday, August 22, 2017 10

Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.

equivalent to the normal user interaction to the GUI. Since this is not a true emulation and it cannot be uses for testing because in that case the event sequence would be different from the real one. --Semyon Thanks and regards, Shashi *From:*Semyon Sadetsky *Sent:* Wednesday, August 23, 2017

Re: [10] Review Request: JDK-8154468 : [TEST_BUG] java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java

+1 --Semyon On 09/06/2017 03:39 AM, Pankaj Bansal wrote: Hi All, Please review the fix for test program java/awt/Window/MultiWindowApp/ChildAlwaysOnTopTest.java for JDK 10. Bug: https://bugs.openjdk.java.net/browse/JDK-8154468 Webrev: http://cr.openjdk.java.net/~aghaisas/pankaj/8154468

[10] Review request for 8148619: Select the closest resolution variant in BaseMultiResolutionImage

Hello, Please review fix for JDK10: bug: https://bugs.openjdk.java.net/browse/JDK-8148619 webrev: http://cr.openjdk.java.net/~ssadetsky/8148619/webrev.00/ The algorithm selecting the best resolution variant of the BaseMultiResolutionImage was updated to be insensitive to the order of image v

Re: [10] Review request for 8148619: Select the closest resolution variant in BaseMultiResolutionImage

RFE which you try to fix cover another use-case: If the user will use the sorted array [@1 ,@20] then we should select @1 if "-Dsun.java2d.uiScale=2" is used but not @20 On 9/6/17 19:31, Semyon Sadetsky wrote: Hello, Please review fix for JDK10: bug: https://bugs.openjdk.java.ne

Re: [10] Review request for 8148619: Select the closest resolution variant in BaseMultiResolutionImage

structure prepared by a certain rule in constructor argument. This API design looks inappropriate to common standard without any significant reason. --Semyon On 9/8/17 11:06, Semyon Sadetsky wrote: On 09/07/2017 01:41 PM, Sergey Bylokhov wrote: Hi, Semyon. The responsibility for sorting of an

[10] Review request for 8186495: Some closed SQE tests fail after frame dispose() on Linux

Hello, Please review fix for JDK10: bug: https://bugs.openjdk.java.net/browse/JDK-8186495 webrev: http://cr.openjdk.java.net/~ssadetsky/8186495/webrev.00/ After toolkit window is destroyed methods invocations on the window component may cause exceptions because of wrong native xwindow ID. The

[10] Review request for 8182043: Access to Windows Large Icons

Hello, Please review fix for JDK10 (the changes involve AWT and Swing): bug: https://bugs.openjdk.java.net/browse/JDK-8182043 webrev: http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.00/ The fix opens the part of the ShellFolder API for getting system icons which was decided to be left c

Re: [10] Review request for 8186495: Some closed SQE tests fail after frame dispose() on Linux

because of absent synchronization on all paths of usage "window",isDispose() and dispose() method: - check isDispose(). - dispose the peer - use the long value which was disposed step above On 9/8/17 20:00, Semyon Sadetsky wrote: Hello, Please review fix for JDK10:

Re: [10] Review request for 8186495: Some closed SQE tests fail after frame dispose() on Linux

11:55 AM, Sergey Bylokhov wrote: On 9/13/17 11:49, Semyon Sadetsky wrote: The tests passes after the fix for me. Which situations do you mean? Can you provide examples? For example in XFramePeer.setVisible() it is possible that the peer became disposed after the new check. --Semyon On 09

Re: [10] Review request for 8186495: Some closed SQE tests fail after frame dispose() on Linux

On 09/13/2017 12:30 PM, Sergey Bylokhov wrote: On 9/13/17 12:19, Semyon Sadetsky wrote: Obviously those peers was not developed with the multi-threaded access kept in mind. It is not obviously since it should be thread safe, and it is already used minimum from 3 threads main/edt/toolkit

Re: [10] Review request for 8186495: Some closed SQE tests fail after frame dispose() on Linux

On 9/13/2017 3:08 PM, Sergey Bylokhov wrote: On 9/13/17 13:19, Semyon Sadetsky wrote: It is not obviously since it should be thread safe, and it is already used minimum from 3 threads main/edt/toolkit. Can you provide examples where dispose() and setVisible() is called simultaneously from

Re: [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

+1 --Semyon On 9/14/2017 3:25 AM, Pankaj Bansal wrote: Hi All, Please review the fix for test program test/java/awt/ComponentOrientation/WindowTest.java for JDK 10. Bug: https://bugs.openjdk.java.net/browse/JDK-8081311 Webrev: http://cr.openjdk.java.net/~aghaisas/pankaj/8081311/webrev.0

Re: [10] Review Request: 8186559 [macos] the screen location is wrong when using AWT/SWT bridge with dual monitors

Hi Sergey, what was caused the regression? --Semyon On 9/14/2017 3:46 PM, Sergey Bylokhov wrote: Hello, Please review the fix for jdk10. Bug: https://bugs.openjdk.java.net/browse/JDK-8186559 Webrev can be found at: http://cr.openjdk.java.net/~serb/8186559/webrev.00 When our NSView is embed

Re: [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

The component orientation test suite should use the right API, not the deprecated one. This was missed when the new API is created. So the change is valid from this point with the corresponding comment in JIRA. --Semyon On 9/15/2017 3:09 PM, Sergey Bylokhov wrote: On 9/14/17 23:15, Pankaj Ba

Re: [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

components via ResourceBudnle or locale is something different that the hardcore the orientation in the application. And the fact that this test found the bug in jdk9 just show that the test is valid. On 9/15/17 16:29, Semyon Sadetsky wrote: The component orientation test suite should use the right API

Re: [10] Review Request: 8186559 [macos] the screen location is wrong when using AWT/SWT bridge with dual monitors

fixed in other places, for example, in CTrayIcon.m line 137 ? On 9/15/17 08:55, Semyon Sadetsky wrote: Hi Sergey, what was caused the regression? --Semyon On 9/14/2017 3:46 PM, Sergey Bylokhov wrote: Hello, Please review the fix for jdk10. Bug: https://bugs.openjdk.java.net/browse/JDK

Re: [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

thing different that the hardcore the orientation in the application. And the fact that this test found the bug in jdk9 just show that the test is valid. On 9/15/17 16:29, Semyon Sadetsky wrote: The component orientation test suite should use the right API, not the deprecated one. This was missed

Re: [10] Review Request: 8178274 Java_sun_lwawt_macosx_NSEvent_nsToJavaKeyInfo() overreads jchar variable

+1 Please, add the corresponding noreg label to the bug. --Semyon On 09/18/2017 01:12 PM, Sergey Bylokhov wrote: Hello, Please review the fix for jdk10. Bug: https://bugs.openjdk.java.net/browse/JDK-8178274 Webrev can be found at: http://cr.openjdk.java.net/~serb/8178274/webrev.00 We pass

Re: [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

On 09/18/2017 11:04 AM, Sergey Bylokhov wrote: On 9/18/17 10:14, Semyon Sadetsky wrote: It is fine because it tests the ComponentOrientation class which is loaded from the resource bundle and applied to the window. I would agree with you if the resource bundle at least contained a value for

Re: [10] Review Request: JDK-6857809 : [TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

Hi Pankaj, The root cause of the issue is that the underling native window is not yet created when its with and height are requested. This is because windows are created asynchronously. The test should be fixed by adding Robot.waitForIdle() after frame.setVisible(true). --Semyon On 09/20/2

Re: [10] Review Request: JDK-6857809 : [TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

real and final frame dimensions will be established asynchronously by the native window subsystem. Regards, Pankaj *From:*Semyon Sadetsky *Sent:* Wednesday, September 20, 2017 9:02 PM *To:* Pankaj Bansal; awt-dev@openjdk.java.net *Subject:* Re: [10] Review Request: JDK-6857809 : [TEST_BUG

Re: [10] Review Request: JDK-6857809 : [TEST_BUG] java/awt/Component/PrintAllXcheckJNI/PrintAllXcheckJNI.java

lt;http://cr.openjdk.java.net/%7Epsadhukhan/pankaj/JDK-6857809-webrev.01/> Regards, Pankaj Bansal *From:*Semyon Sadetsky *Sent:* Wednesday, September 20, 2017 10:43 PM *To:* Pankaj Bansal; awt-dev@openjdk.java.net *Subject:* Re: [10] Review Request: JDK-6857809 : [TEST_BUG] java/awt/Component/PrintAl

Re: [10] Review request for 8182043: Access to Windows Large Icons

/etc) of supported sizes, and the user will be able to pass some meaningful sizes. This is not a good idea. Extracting all available icon resolutions might take significant time and since icons are cached it would be waste of RAM. On 9/13/17 11:01, Semyon Sadetsky wrote: Hello, Please review fi

Re: [10] Review request for 8186495: Some closed SQE tests fail after frame dispose() on Linux

On 09/13/2017 03:42 PM, Sergey Bylokhov wrote: On 9/13/17 15:36, Semyon Sadetsky wrote: The problem in the fix is that the new checks do not try to be thread safe. So, what do you propose? Add a volatile field "disposing" and do noop if it is true? I have added a links to the

Re: [10] Review request for 8182043: Access to Windows Large Icons

On 09/21/2017 01:52 PM, Sergey Bylokhov wrote: On 9/21/17 08:54, Semyon Sadetsky wrote: On 09/20/2017 02:41 PM, Sergey Bylokhov wrote: Hi, Semyon I have some initial comments which are based on the two bugs: JDK-8182043 and JDK-8156183. getSystemIcon(File file, int size): - How the

Re: [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java

- From: Semyon Sadetsky Sent: Tuesday, September 19, 2017 8:40 PM To: Sergey Bylokhov; Pankaj Bansal; awt-dev@openjdk.java.net Subject: Re: [10] Review Request: JDK-8081311 : [TEST_BUG] java/awt/ComponentOrientation/WindowTest.java On 09/18/2017 11:04 AM, Sergey Bylokhov wrote: On 9/18/17 10

Re: [10] Review request for 8182043: Access to Windows Large Icons

Hi Alexey, Thank you for your exact clarification. On 09/22/2017 04:22 AM, Alexey Ivanov wrote: Hi Sergey, On 22/09/2017 04:21, Sergey Bylokhov wrote: On 9/21/17 14:12, Semyon Sadetsky wrote: On 09/21/2017 01:52 PM, Sergey Bylokhov wrote: On 9/21/17 08:54, Semyon Sadetsky wrote: On 09/20

Re: [10] Review request for 8182043: Access to Windows Large Icons

Hi Alexey, On 09/22/2017 09:43 AM, Alexey Ivanov wrote: Hi Semyon, On 22/09/2017 17:13, Semyon Sadetsky wrote: Hi Alexey, Thank you for your exact clarification. On 09/22/2017 04:22 AM, Alexey Ivanov wrote: As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using Windows A

Re: [10] Review request for 8182043: Access to Windows Large Icons

Hi Alexey, On 09/22/2017 10:53 AM, Alexey Ivanov wrote: Hi Semyon, On 22/09/2017 18:29, Semyon Sadetsky wrote: Hi Alexey, On 09/22/2017 09:43 AM, Alexey Ivanov wrote: Hi Semyon, On 22/09/2017 17:13, Semyon Sadetsky wrote: Hi Alexey, Thank you for your exact clarification. On 09/22/2017

Re: [10] Review request for 8182043: Access to Windows Large Icons

Hi Alexey, On 09/22/2017 01:01 PM, Alexey Ivanov wrote: Hi Semyon, On 22/09/2017 20:06, Semyon Sadetsky wrote: Hi Alexey, On 09/22/2017 10:53 AM, Alexey Ivanov wrote: Hi Semyon, On 22/09/2017 18:29, Semyon Sadetsky wrote: Hi Alexey, On 09/22/2017 09:43 AM, Alexey Ivanov wrote: Hi

Re: [10] Review request for 8155197: Focus transition issue

Hi Dmitry, This issue was already fixed in 9. See 8139218 & 8159432. --Semyon On 09/23/2017 08:25 AM, Dmitry Markov wrote: Hello, Could you review a fix for jdk10, please? bug: https://bugs.openjdk.java.net/browse/JDK-8155197 webrev: http://cr.openjdk.java.net/~dmarkov/8155197/webrev.

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

Hi Alexander, On the Windows platform you've only modified the dialog native peer while on other platforms all window types are modified to use FX window as a parent. Shouldn't the frame native peer be modified too on the Windows platform? --Semyon On 09/21/2017 10:56 PM, Alexander Zvegin

Re: [10] Review request for 8155197: Focus transition issue

ative window already has the focus this should be very deterministic. --Semyon Thanks, Dmitry On 25 Sep 2017, at 15:58, Semyon Sadetsky wrote: Hi Dmitry, This issue was already fixed in 9. See 8139218 & 8159432. --Semyon On 09/23/2017 08:25 AM, Dmitry Markov wrote: Hello, Could you

Re: [10] Review request for 8155197: Focus transition issue

Hi Dmitry, On 9/26/2017 1:56 AM, Dmitry Markov wrote: Hi Semyon, Please find my answer inline. Thanks, Dmitry On 25 Sep 2017, at 22:26, Semyon Sadetsky wrote: Hi Dmitry, On 09/25/2017 01:09 PM, Dmitry Markov wrote: Hi Semyon, This issue and the problem addressed by 8139218 and 8159432

Re: [10] Review request for 8182043: Access to Windows Large Icons

l. It's better to leave it as it is. http://cr.openjdk.java.net/~ssadetsky/8182043/webrev.02/ --Semyon Regards, Alexey On 22/09/2017 22:05, Semyon Sadetsky wrote: Hi Alexey, On 09/22/2017 01:01 PM, Alexey Ivanov wrote: Hi Semyon, On 22/09/2017 20:06, Semyon Sadetsky wrote: Hi Al

Re: [10] Review request for 8182043: Access to Windows Large Icons

Hi Sergey, On 9/25/2017 1:44 PM, Sergey Bylokhov wrote: On 9/22/17 04:22, Alexey Ivanov wrote: There's no way of knowing in advance. Explorer does not restrict the size of icons (now), it's up to developers of a particular file handler to provide icons. Usually, there's only one icon with siz

Re: [10] Review request for 8155197: Focus transition issue

screen for a longer while, the test does not fail either. Regards, Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8155197 On 26/09/2017 23:46, Semyon Sadetsky wrote: Hi Dmitry, On 9/26/2017 1:56 AM, Dmitry Markov wrote: Hi Semyon, Please find my answer inline. Thanks, Dmitry On 25

Re: [10] Review request for 8155197: Focus transition issue

case the focus is directly restored to the previously focused window which doesn't have the focus at this moment and input focus cannot be requested to one of its components synchronously. Please confirm whether you agree on the root cause of the bug. --Semyon Thanks, Dmitry On 28 Sep

Re: [10] Review request for 8182043: Access to Windows Large Icons

Hi Alexey, On 9/28/2017 7:28 AM, Alexey Ivanov wrote: I think 0 should really be |NULL|. Ok, but both represent the null pointer in Win32. Yes, I know. Yet NULL makes it clear that it's a null-pointer rather than an index, size… It's still zero in the latest review. Agh... I will fix it in

Re: [10] Review request for 8182043: Access to Windows Large Icons

Hi Sergey, On 9/27/2017 12:22 PM, Sergey Bylokhov wrote: On 9/26/17 14:37, Semyon Sadetsky wrote: This means that on HiDPI screen the FILE_ICON_LARGE works in similar way as FILE_ICON_SMALL on non-HiDPI screen, and the meaning of the FILE_ICON_SMALL on HiDPI is unclear, because it is half of

Re: [10] Review request for 8182043: Access to Windows Large Icons

On 9/28/2017 10:51 AM, Philip Race wrote: If this is up for consideration for backporting - as appears to be the case - then I think you should post an updated webrev. Not sure that we can backport it because this would change the API. --Semyon -phil.

Re: [10] Review request for 8182043: Access to Windows Large Icons

On 9/29/2017 12:29 PM, Sergey Bylokhov wrote: On 9/29/17 07:34, Alexey Ivanov wrote: Ok, so it means that we will support 1-128 pixels natively(MAX_ICON_SIZE) and others via MRI. Why 128 pixels? Windows shell usually provides icons up to 256 pixels, for example there are 256×256 icons for f

Re: [10] Review request for 8182043: Access to Windows Large Icons

On 9/29/2017 3:15 PM, Sergey Bylokhov wrote: On 9/29/17 12:39, Semyon Sadetsky wrote: Why 128 pixels? Windows shell usually provides icons up to 256 pixels, for example there are 256×256 icons for folders and generic file type. It is limitation of our implementation: https

[10] Review request for 8183504: 8u131 Win 10, issue with wrong position of Sogou IME popup

Hello, Please review fix for JDK10: bug: https://bugs.openjdk.java.net/browse/JDK-8183504 webrev: http://cr.openjdk.java.net/~ssadetsky/8183504/webrev.00 Sogou Pinyin is an 3rd party app [1], but it looks like that it is the most popular input method in China [2]. Sogou Pinyin acts in differe

Re: [10] Review request for 8155197: Focus transition issue

Hi Dmitry, Actually the parent frame doesn't own the input focus when the issue happens. The focus is on the dialog already and when FOCUS_GAINED event comes for the dialog the KFM discovers that the dialog should not have the focus and rejects it in line 588 of the DefaultKeyboardFocusManage

Re: [10] Review request for 8155197: Focus transition issue

ed the test to simplify it. Thanks, Dmitry On 2 Oct 2017, at 18:32, Semyon Sadetsky <mailto:semyon.sadet...@oracle.com>> wrote: Hi Dmitry, Actually the parent frame doesn't own the input focus when the issue happens. The focus is on the dialog already and when FOCUS_GAINED event

Re: [10] Review request for 8155197: Focus transition issue

Also I slightly modified the test to simplify it. Thanks, Dmitry On 2 Oct 2017, at 18:32, Semyon Sadetsky <mailto:semyon.sadet...@oracle.com><mailto:semyon.sadet...@oracle.com>> wrote: Hi Dmitry, Actually the parent frame doesn't own the input focus when the issue happen

Re: [10] Review request for 8155197: Focus transition issue

still may be set as most recent focus owner. This makes the isShowing() check mandatory for component returned by getMostRecentFocusOwner(). --Semyon Thanks, Dmitry On 4 Oct 2017, at 17:23, Semyon Sadetsky <mailto:semyon.sadet...@oracle.com>> wrote: Hi Dmitry, If you make a detailed

Re: [10] Review request for 8155197: Focus transition issue

OK, looks good to me, thanks. --Semyon On 10/05/2017 02:15 PM, Dmitry Markov wrote: Hi Semyon, On 5 Oct 2017, at 17:13, Semyon Sadetsky <mailto:semyon.sadet...@oracle.com>> wrote: Hi Dmitriy, On 10/05/2017 07:25 AM, Dmitry Markov wrote: Hi Semyon, Actually the most recent focus

[10] Review request for 8182638: [macosx] Active modal dialog is hidden by another non-active one

Hello, Please review fix for JDK10: bug: https://bugs.openjdk.java.net/browse/JDK-8182638 webrev: http://cr.openjdk.java.net/~ssadetsky/8182638/webrev.00/ Since 8169589 sibling windows are ordered above the parent. It requires for the new active child windows to be raised above its siblings

Re: [10] Review request for 8182043: Access to Windows Large Icons

On 10/06/2017 12:38 PM, Sergey Bylokhov wrote: On 10/6/17 09:53, Alexey Ivanov wrote: It is limitation of our implementation: https://bugs.openjdk.java.net/browse/JDK-8151385 http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010777.html I see. And it can be changed, if deemed necessar

Re: [10] Review request for 8182043: Access to Windows Large Icons

Hi Alexey, On 10/06/2017 11:42 AM, Alexey Ivanov wrote: Hi Semyon, Sergey, On 30/09/2017 00:08, Semyon Sadetsky wrote: On 9/29/2017 3:15 PM, Sergey Bylokhov wrote: On 9/29/17 12:39, Semyon Sadetsky wrote: Why 128 pixels? Windows shell usually provides icons up to 256 pixels, for example

Re: [10] Review request for 8182043: Access to Windows Large Icons

On 10/06/2017 01:16 PM, Sergey Bylokhov wrote: On 10/6/17 13:01, Semyon Sadetsky wrote: On 10/06/2017 12:38 PM, Sergey Bylokhov wrote: On 10/6/17 09:53, Alexey Ivanov wrote: It is limitation of our implementation: https://bugs.openjdk.java.net/browse/JDK-8151385 http://mail.openjdk.java.net

Re: [10] Review request for 8182043: Access to Windows Large Icons

On 10/06/2017 03:57 PM, Sergey Bylokhov wrote: On 10/6/17 13:50, Semyon Sadetsky wrote: This is not true because in addition to LARGE which you probably mean as 32-128 (ignoring the fact that this sizes may be changed in the Windows registry), Windows supports EXTRA_LARGE and JAMBO since

Re: [10] Review Request: 8187639 TrayIcon is not properly supported on macOS in multi-screen environment

Hi Sergey, The suggested replacing the Swing dialog with the native notification popup seems too radical change for the issue. It might be justified in case of the System LnF, but even in this case I'm not sure, because of possible compatibility problems. --Semyon On 09/27/2017 10:07 AM, S

[10] Review request for 8074824: Resolve disabled warnings for libawt_xawt

Hello, Please review fix for JDK10: bug:https://bugs.openjdk.java.net/browse/JDK-8074824 webrev: http://cr.openjdk.java.net/~ssadetsky/8074824/webrev.00/ The eliminates gcc warnings produced during compilation of xawt library. --Semyon

Re: [10] Review Request: 8187639 TrayIcon is not properly supported on macOS in multi-screen environment

like the old code, it looks is native, it works in a multi-screen environment. I think that we should implement the same fix for linux/windows as well at some point. On 09/10/2017 09:19, Semyon Sadetsky wrote: Hi Sergey, The suggested replacing the Swing dialog with the native notification

Re: [10] Review request for 8074824: Resolve disabled warnings for libawt_xawt

74824/webrev.01/ Before and after this path the sun/java2d/* tests ran with -Dsun.java2d.opengl=True are in the same shape: 5 failures and 1 error. --Semyon -phil. On 10/13/2017 11:20 AM, Semyon Sadetsky wrote: Hello, Please review fix for JDK10: bug:https://bugs.openjdk.java.net/browse/JDK-

Re: [10] Review request for 8074824: Resolve disabled warnings for libawt_xawt

Hi Sergey, On 10/16/2017 04:45 PM, Sergey Bylokhov wrote: Hi, Semyon. A few notes:> I ran OGL tests and found a typo. Below the update webrev> http://cr.openjdk.java.net/~ssadetsky/8074824/webrev.01/  - What is a typo? It seems the v0 and v1 are identical. It's in line 516 of the OGLPaints.c

Re: [10] Review request for 8074824: Resolve disabled warnings for libawt_xawt

AM To: Semyon Sadetsky; Phil Race; awt-dev@openjdk.java.net Subject: Re: [10] Review request for 8074824: Resolve disabled warnings for libawt_xawt Hi, Semyon. A few notes:> I ran OGL tests and found a typo. Below the update webrev> http://cr.openjdk.java.net/~ssadetsky/8074824/web

[10] Review request for 8189201: [macosx] NotSerializableException during JFrame with MenuBar serialization

Hello, Please review fix for JDK10: bug: https://bugs.openjdk.java.net/browse/JDK-8189201 webrev: http://cr.openjdk.java.net/~ssadetsky/8189201/webrev.00 The root cause is that several JFrame fields contain non-serializable class instances. The fix marks those classes as serializable. --Sem

Re: [10] Review Request: 8186559 [macos] the screen location is wrong when using AWT/SWT bridge with dual monitors

+1 --Semyon On 09/18/2017 03:04 PM, Sergey Bylokhov wrote: On 9/18/17 09:53, Semyon Sadetsky wrote: On 09/15/2017 02:29 PM, Sergey Bylokhov wrote: It is broken from the moment when it was implemented(I have rechecked on 8u121 which was mentioned in the report), unlike Apple jdk where it

Re: [10] Review request for 8189201: [macosx] NotSerializableException during JFrame with MenuBar serialization

d during deserialization the L&F of the target system should be applied. That is valid concern. The webrev is updated http://cr.openjdk.java.net/~ssadetsky/8189201/webrev.01/ --Semyon On 20/10/2017 13:08, Semyon Sadetsky wrote: Hello, Please review fix for JDK10: bug: https://bugs.open

Re: [10] Review request for 8189201: [macosx] NotSerializableException during JFrame with MenuBar serialization

On 10/23/2017 12:58 PM, Sergey Bylokhov wrote: On 23/10/2017 12:41, Semyon Sadetsky wrote: The AquaMenuBarBorder class is L&F specific, and it should not be serialized/deserialized. Such information(plus l&f client properties/listeners/etc) should be removed from the component

Re: [10] Review request for 8189201: [macosx] NotSerializableException during JFrame with MenuBar serialization

Actually ScreenMenu is fully removed in uninstallUI() (line 54 of AquaMenuBarUI), so there is no need to make its property listener Serializable, please, ignore the change in ScreenMenuPropertyListener. --Semyon On 10/23/2017 01:25 PM, Semyon Sadetsky wrote: On 10/23/2017 12:58 PM, Sergey

Re: [10] Review Request: 8182410, 8183508, 8181289

Hi Sergey, I see no reason to have an extra empty anchor tag to set a bookmark. The id attribute works with any element. For example:         Definitions should be     Definitions --Semyon On 10/23/2017 02:42 PM, Sergey Bylokhov wrote: Hello, Please review the fix for. 8182410: missing

Re: [10] Review Request: 8182410, 8183508, 8181289

updated according to it. In html5 you need only if you want to see hyperlink and your fix is modifying those tags. --Semyon On 23/10/2017 22:08, Semyon Sadetsky wrote: Hi Sergey, I see no reason to have an extra empty anchor tag to set a bookmark. The id attribute works with any element

Re: [10] Review request for 8183504: 8u131 Win 10, issue with wrong position of Sogou IME popup

below text component caret. However  in windows 7, even without your fix, I find the sogou input appearing below text component caret. Yes, but 9 has infinite recursion when IME composition window appears. --Semyon Regards Prasanta On 10/2/2017 8:48 PM, Semyon Sadetsky wrote: Hello

[10] Review request for 8189204: Possible NPE in Component::getLocationOnScreen()

Hello, Please review fix for JDK10: bug: https://bugs.openjdk.java.net/browse/JDK-8189204 webrev: http://cr.openjdk.java.net/~ssadetsky/8189204/webrev.00/ The fix eliminates possibility of NPEs in Component ::getLocationOnScreen().  Method Component ::getLocationOnScreen_NoTreeLock() does no

Re: [10] Review Request: 8182410, 8183508, 8181289

difference between navigating to " --Semyon [1] https://www.w3schools.com/html/html_links.asp [2] http://www.html5-tutorials.org/html-basics/links/ [3] https://www.w3.org/TR/html5/browsers.html#scroll-to-fragid -- Jon On 10/23/2017 10:08 PM, Semyon Sadetsky wrote: Hi Sergey, I see no re

Re: [10] Review Request: 8187639 TrayIcon is not properly supported on macOS in multi-screen environment

On 10/25/2017 06:49 PM, Sergey Bylokhov wrote: On 16/10/2017 12:14, semyon.sadet...@oracle.com wrote: But what to do with compatibility issues? Do you provide any options to run existing applications? The existing applications will use the new functionality which behaves like the old ones. T

Re: [10] Review request for 8183504: 8u131 Win 10, issue with wrong position of Sogou IME popup

nt meaning? Regards Prasanta On 10/26/2017 11:10 AM, Prasanta Sadhukhan wrote: Hi Semyon, It now works for windows10 but regress in windows 7 for me, where no Sogou input window appears below text component. Regards Prasanta On 10/26/2017 4:52 AM, Semyon Sadetsky wrote: Hi Prasanta, Ple

Re: [10] Review Request: 8187639 TrayIcon is not properly supported on macOS in multi-screen environment

On 10/26/2017 12:45 PM, Sergey Bylokhov wrote: On 26/10/2017 08:26, Semyon Sadetsky wrote: The existing applications will use the new functionality which behaves like the old ones. The appearance of the message itself will differ but after the fix it will look like the native message, even

<    1   2   3   4   5   6   7   >