AWT Dev [8] Review request for 8015375: Edits to text components hang for clipboard access

Hello, Could you review the fix, please? bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015375 webrev: http://cr.openjdk.java.net/~vkarnauk/8015375/webrev.00/ The function XNextSecondaryLoopEvent() should use a progressive time out value instead of hardcoded 250 msces during

Re: AWT Dev [8] Review request for 8015375: Edits to text components hang for clipboard access

simplify the logic. But I'm OK with the current version as well. See for yourself if you want to update the fix. In any case, we need at least one more reviewer for this patch. -- best regards, Anthony On 05/27/2013 04:28 PM, dmitry markov wrote: Hello, Could you review the fix, please? bug

Re: AWT Dev [8] Review request for 8015375: Edits to text components hang for clipboard access

Hello, A gentle reminder. Could you review this, please? Thank you in advance, Dmitry On 30/05/2013 08:50, dmitry markov wrote: Hi Anthony, Thank you for taking a look. If you do not mind, I'd prefer to stay the fix as is. Could anyone else review the changes, please? Thank you

AWT Dev Swing Dev [8] Review request for 8023474: First mousepress doesn't start editing in JTree

Hello, Could you review the fix, please? bug: http://bugs.sun.com/view_bug.do?bug_id=8023474 webrev: http://cr.openjdk.java.net/~dmarkov/8023474/webrev.00/ The method BasicTreeUI.startEditing() should find the first valid root for the editingComponent and call validateUnconditionally()

Re: AWT Dev Swing Dev [8] Review request for 8023474: First mousepress doesn't start editing in JTree

Swing components allow for editors? As far as I know, JTable does not have this problem. -- best regards, Anthony On 08/22/13 15:08, dmitry markov wrote: Hello, Could you review the fix, please? bug: http://bugs.sun.com/view_bug.do?bug_id=8023474 webrev: http://cr.openjdk.java.net/~dmarkov

AWT Dev [7u] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol

Hello, Could you review a back-port of 7129133 to JDK 7u, please? The back-port and the main fix integrated into jdk8 are slightly different. bug: http://bugs.sun.com/view_bug.do?bug_id=7129133 webrev for jdk7u: http://cr.openjdk.java.net/~dmarkov/7129133/webrev.00/ jdk8 changeset:

AWT Dev [7u] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.

Hello, Could you review a back-port of 7171045 to JDK 7u, please? The back-port and the main fix integrated into JDK 8 are slightly different. bug: http://bugs.sun.com/view_bug.do?bug_id=7171045 webrev for jdk7u: http://cr.openjdk.java.net/~dmarkov/7171045/jdk7u/webrev.00/ jdk8 changeset:

Re: AWT Dev [7u] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.

Reminder. Could you review this, please? Thanks, Dmitry On 11/02/2014 13:46, dmitry markov wrote: Hello, Could you review a back-port of 7171045 to JDK 7u, please? The back-port and the main fix integrated into JDK 8 are slightly different. bug: http://bugs.sun.com/view_bug.do?bug_id

Re: AWT Dev [7u] Review request for 7171045 [macosx] There are no enter or exit events reported against 8b39 for MouseEventsDuringDrag.

to NSTrackingActiveAlways for the resetTrackingRect method in the AWTView.m file for the backport? http://mail.openjdk.java.net/pipermail/awt-dev/2013-August/005347.html http://cr.openjdk.java.net/~pchelko/8012026/webrev.00/ Thanks, Alexandr. On 2/11/2014 1:46 PM, dmitry markov wrote: Hello

AWT Dev [9] Review Request: JDK-8032872: [macosx] Cannot select from JComboBox in a JWindow

Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8032872 webrev: http://cr.openjdk.java.net/~dmarkov/8032872/jdk9/webrev.00/ Problem description: It is impossible to make a selection in JComboBox added to JWindow via the mouse. The problem is

Re: AWT Dev [9] Review Request: JDK-8032872: [macosx] Cannot select from JComboBox in a JWindow

was investigating this I did not understand why that was done that way. Do you know the reason? May be it's better not in introduce a new function but replace the getOwnerFrameDialog with your new implementation? Thank you. With best regards. Petr. On 03.03.2014, at 13:45, dmitry markov dmitry.mar

AWT Dev [7u] Review request for 8012026: [macosx] Component.getMousePosition() does not work in an applet on MacOS

Hello, Could you review a straight back-port of 8012026 to jdk7u, please? bug: https://bugs.openjdk.java.net/browse/JDK-8012026 webrev for jdk7u: http://cr.openjdk.java.net/~dmarkov/8012026/jdk7u/webrev.00/ jdk8 changeset: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/17cc8f13e4e7 technical

Re: AWT Dev [9] Review Request: JDK-8032872: [macosx] Cannot select from JComboBox in a JWindow

recommend to add a new testcase to java/awt/Window/Grab/GrabTest.java Thanks, Anton. On 03.03.2014 16:49, Sergey Bylokhov wrote: On 3/3/14 2:22 PM, dmitry markov wrote: If I get it right, getOwnerFrameDialog() is designed for another purpose. Also it is NOT only used in notifyMouseEvent

Re: AWT Dev [9] Review Request: JDK-8032872: [macosx] Cannot select from JComboBox in a JWindow

for adding this case to java/awt/Window/Grab/GrabTest.java Thanks, Anton. On 04.03.2014 17:26, dmitry markov wrote: Hello, Could you review the updated fix, please? webrev: http://cr.openjdk.java.net/~dmarkov/8032872/jdk9/webrev.01/ - Fixed problem in changeFocusedWindow() - Added description

Re: AWT Dev [9] Review Request: JDK-8032872: [macosx] Cannot select from JComboBox in a JWindow

, if I didn't make that clear. So, the simple case is to have a hierarchy: frame - window-1 - window-2, where window-1 is grabbed. Then you click in window-2 and check if it doesn't cause ungrab event. Right? Thanks, Anton. On 05.03.2014 12:55, dmitry markov wrote: Hi Anton, I updated java

Re: AWT Dev [9] Review Request: JDK-8036112: JColorChooser throws a NPE when applet with static reference is reloaded

AppContext should be changed. But it may take a lot of time and significantly increase the applet's relaunch time, since the structure of static field may be quite complex. And i think appContext.getAppContext() can be null too. On 4/1/14 3:02 PM, dmitry markov wrote: Hello, Could you

AWT Dev [9] Review request for 8042465: Applet menus not rendering when browser is full screen on Mac

Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8042465 webrev: http://cr.openjdk.java.net/~dmarkov/8042465/jdk9/webrev.00/ Problem description: On Mac OS X when a browser is in full screen mode, applet's popup is displayed behind the

Re: AWT Dev [9] Review request for 8042465: Applet menus not rendering when browser is full screen on Mac

. But it will be visible for enough time to get noticed and annoying. And also, why are you explicitly setting 18 instead of using the name of the constant? Thank you. With best regards. Petr. On 14 мая 2014 г., at 12:54, dmitry markov dmitry.mar...@oracle.com wrote: Hello, Could you review the fix

Re: AWT Dev [9] Review request for 8042465: Applet menus not rendering when browser is full screen on Mac

/2014 11:04, dmitry markov wrote: Hi Petr, Anthony, Thank you for looking at this. I really missed the case pointed out by Petr. If the test app is running in browser instead of IDE or appletviewer, the situation is much worse - the opened popup does not hide at all when we switch to another

Re: AWT Dev [9] Review request for 8042465: Applet menus not rendering when browser is full screen on Mac

when an app is running with the default LF. What is the solution for custom LFs? Can we move the logic for cache disabling to the shared popup-related code somewhere so that the issue is fixed for all LFs at once? -- best regards, Anthony On 5/26/2014 4:08 PM, dmitry markov wrote: Hello, Could

AWT Dev [9] Review request for 8044614: [macosx] Focus issue with 2 applets in firefox

Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8044614 webrev: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/ Problem description: on Mac OSX when switching between several applets running in separate browser's windows, the

Re: AWT Dev [9] Review request for 8044614: [macosx] Focus issue with 2 applets in firefox

the focus? Thanks, Alexandr. On 7/2/2014 2:45 PM, dmitry markov wrote: Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8044614 webrev: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.00/ Problem description: on Mac OSX when

Re: AWT Dev [9] Review request for 8044614: [macosx] Focus issue with 2 applets in firefox

scratch. Thanks, Alexandr. On 7/16/2014 4:08 PM, dmitry markov wrote: Hi Alexandr, I am sorry for the delay. When a browser's window becomes active/inactive, the browser generates WindowFocusEvent and sends it to the applets via Java Plugin. So the order of the events is defined

Re: AWT Dev [9] Review request for 8044614: [macosx] Focus issue with 2 applets in firefox

/18/2014 3:52 PM, dmitry markov wrote: Hi Alexandr, Please find answer below. Thanks, Dmitry On 17/07/2014 14:18, Alexander Scherbatiy wrote: The pluginFocusedWindow is only updated after switching from one browser to another (after WindowFocusEvent event). Should it also be updated after

Re: AWT Dev [9] Review request for 8044614: [macosx] Focus issue with 2 applets in firefox

updated the field's name. Please find new version here: http://cr.openjdk.java.net/~dmarkov/8044614/jdk9/webrev.03/ With best regards. Petr. On 23 июля 2014 г., at 11:29, dmitry markov dmitry.mar...@oracle.com wrote: Hello, Could anyone else review the fix, please? https://bugs.openjdk.java.net

AWT Dev [9] Review request for 8073453: Focus doesn't move when pressing Shift + Tab keys

Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8073453 webrev: http://cr.openjdk.java.net/~dmarkov/8073453/jdk9/webrev.00/ Problem description: The method ContainerOrderFocusTraversalPolicy.getLastComponent() always returns null if the

Re: [9] Review request for 8025130: [macosx] Frame setLocationByPlatform has no effect under Mac OS X

. In the test please dispose frames in case of exception and don't forget to set the correct GPL year in AWTWindow.m. --Semyon On 6/8/2016 10:07 AM, dmitry markov wrote: Any volunteers to review the fix? Thanks in advance, Dmitry On 02/06/2016 11:18, dmitry markov wrote: Hello, Could you review

Re: [9] Review request for 8025130: [macosx] Frame setLocationByPlatform has no effect under Mac OS X

Any volunteers to review the fix? Thanks in advance, Dmitry On 02/06/2016 11:18, dmitry markov wrote: Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8025130 webrev: http://cr.openjdk.java.net/~dmarkov/8025130/webrev.00/ Problem

[9] Review request for 8025130: [macosx] Frame setLocationByPlatform has no effect under Mac OS X

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8025130 webrev: http://cr.openjdk.java.net/~dmarkov/8025130/webrev.00/ Problem description: Invocation of setLocationByPlatform() has no effect under Mac OS X, (i.e. the feature is not fully

Re: [9] Review request for 8154816: Caps Lock doesn't work as expected when using Pinyin Simplified input method

Sadetsky wrote: Hi Dmitry, The fix looks good. I am only not sure that an applet based test is suitable since applets are deprecated. --Semyon On 6/17/2016 1:45 PM, dmitry markov wrote: Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8154816

[9] Review request for 8148984: [macosx] Chinese Comma cannot be entered using Pinyin Input Method on OS X

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8148984 webrev: http://cr.openjdk.java.net/~dmarkov/8148984/webrev.00/ Problem description: 'Latin comma' character is entered in text component instead of the required 'fullwidth comma'

[9] Review request for 8154816: Caps Lock doesn't work as expected when using Pinyin Simplified input method

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8154816 webrev: http://cr.openjdk.java.net/~dmarkov/8154816/webrev.00/ Problem description: When Pinyin Simplified input method is selected and 'Caps Lock' is on, input is switched to latin

Re: [9] Review request for 8080729: [macosx] java 7 and 8 JDialogs on multiscreen jump to parent frame on focus

Any volunteers to review the fix? Thanks in advance, Dmitry On 21/04/2016 10:21, dmitry markov wrote: Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8080729 webrev: http://cr.openjdk.java.net/~dmarkov/8080729/webrev.00/ Problem

Re: [9] Review request for 8080729: [macosx] java 7 and 8 JDialogs on multiscreen jump to parent frame on focus

ame level). On 28 Apr 2016, at 16:24, dmitry markov <dmitry.mar...@oracle.com <mailto:dmitry.mar...@oracle.com>> wrote: Anton, Let me clarify the implementation of orderChilds() function. It is responsible for proper windows ordering, (i.e. child windows should be always

Re: [9] Review request for 8080729: [macosx] java 7 and 8 JDialogs on multiscreen jump to parent frame on focus

Anton, Thank you for the review. Can anyone else review the fix, please? Thanks, Dmitry On 29/04/2016 10:25, Anton Tarasov wrote: On 29 Apr 2016, at 09:50, dmitry markov <dmitry.mar...@oracle.com <mailto:dmitry.mar...@oracle.com>> wrote: The main idea of suggested implementatio

Re: [9] Review request for 8080729: [macosx] java 7 and 8 JDialogs on multiscreen jump to parent frame on focus

name “Childs” in the new methods to “Children” or to “ChildWindows”? Thanks, Anton. On 28 Apr 2016, at 10:06, dmitry markov <dmitry.mar...@oracle.com <mailto:dmitry.mar...@oracle.com>> wrote: Hi Anton, Thank you for your feedback. You are right, in some cases B may be ordered above C

Re: [9] Review request for 8080729: [macosx] java 7 and 8 JDialogs on multiscreen jump to parent frame on focus

On 25 Apr 2016, at 22:35, dmitry markov <dmitry.mar...@oracle.com> wrote: Any volunteers to review the fix? Thanks in advance, Dmitry On 21/04/2016 10:21, dmitry markov wrote: Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8080729

Re: [9] Review request for 8157322: Several typos in javadoc

(UnsupportedAudioFileException.java for example). It is not necessary to send a new webrev. On 19.05.16 13:35, dmitry markov wrote: Hello, Could you review a simple fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8157322 webrev: http://cr.openjdk.java.net/~dmarkov/8157322/webrev.00/ Fixed

[9] Review request for 8157322: Several typos in javadoc

Hello, Could you review a simple fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8157322 webrev: http://cr.openjdk.java.net/~dmarkov/8157322/webrev.00/ Fixed several typos in client libraries javadoc. Thanks, Dmitry

Re: [9] Review request for 8155001: SystemTray.remove() leaks GDI Objects in Windows

/05/2016 17:06, Sergey Bylokhov wrote: Hi, Dmitry. Is it possible that m_nid.hIcon will be NULL in dispose()? On 06.05.16 14:48, dmitry markov wrote: Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8155001 webrev: http

[9] Review request for 8080729: [macosx] java 7 and 8 JDialogs on multiscreen jump to parent frame on focus

Hello, Could you review the fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8080729 webrev: http://cr.openjdk.java.net/~dmarkov/8080729/webrev.00/ Problem description: On OS X platform in dual monitor setup a child window jumps to another monitor where a

[9] Review request for 8163583: [macosx] Press "To Back" button on the Dialog, the Dialog moves behind the Frame

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8163583 webrev: http://cr.openjdk.java.net/~dmarkov/8163583/webrev.00/ Problem description: If toBack() method is invoked on dialog/frame which has not-null owner, the dialog/frame will be

Re: [9] Review request for 8148984: [macosx] Chinese Comma cannot be entered using Pinyin Input Method on OS X

Hello Alex, Thank you for review. Can anyone else review the fix, please? Thanks, Dmitry On 23/06/2016 16:55, Alexander Potochkin wrote: Hello Dmitry The fix looks good! Thanks alexp On 6/17/2016 15:39, dmitry markov wrote: Hello, Could you review a fix for jdk9, please? bug: https

Re: [9] Review request for 8163583: [macosx] Press "To Back" button on the Dialog, the Dialog moves behind the Frame

Just in case JCK tests passed on the build with fix. Thanks, Dmitry On 15/08/2016 14:08, dmitry markov wrote: Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8163583 webrev: http://cr.openjdk.java.net/~dmarkov/8163583/webrev.00/ Problem

Re: AWT Dev> [9] Review request for 8163979: [macosx] Chinese text shows as Latin w/ openVanilla input method

, Dmitry > On 13 Feb 2017, at 16:58, Dmitry Markov <dmitry.mar...@oracle.com> wrote: > > Hello, > > Could you review a fix for jdk9, please? > > bug: https://bugs.openjdk.java.net/browse/JDK-8163979 > webrev: http://cr.openjdk.java.net/~dmarkov/8163979/webre

Re: AWT Dev> [9] Review request for 8163979: [macosx] Chinese text shows as Latin w/ openVanilla input method

x, (i.e. >> http://cr.openjdk.java.net/~dmarkov/8163979/webrev.00/). It releases >> currenLocale two times. >> The correct version is located at >> http://cr.openjdk.java.net/~dmarkov/8163979/webrev.01/ >> Could you review the updated fix, please? >> >>

Re: [9] Review request for 8050478: [macosx] Cursor not updating correctly after closing a modal dialog

Thank you very much, Sergey! Looking for a second +1 from someone else. Thanks, Dmitry > On 29 Aug 2016, at 18:53, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > > Looks fine. > > On 25.08.16 13:53, Dmitry Markov wrote: >> Hi Sergey, >> >> I have u

[9] Review request for 8169355: Diacritics input works incorrectly on Windows if Spanish (Latin American) keyboard layout is used

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8169355 webrev: http://cr.openjdk.java.net/~dmarkov/8169355/webrev.00/ Problem description: The new mechanism of dead keys detection and processing was introduced by JDK-8139189

Re: [9] Review request for 8158262: Diacritics input works incorrectly if event processing is delayed on Windows

:17 PM, Semyon Sadetsky wrote: Hello Dmitry, Did you run all cases of java/awt/InputMethods/DiacriticsTest/DiacriticsTest.html after the fix? Could you add the current case to DiacriticsTest.html as well? --Semyon On 11/7/2016 2:41 PM, dmitry markov wrote: Hello, Could you review a fix

[9] Review request for 8158262: Diacritics input works incorrectly if event processing is delayed on Windows

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8158262 webrev: http://cr.openjdk.java.net/~dmarkov/8158262/webrev.00/ Problem description: The new mechanism of dead keys detection and processing was introduced by JDK-8139189

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

is one of ancestors of the specified window. Thanks, Dmitry On 25 Nov 2016, at 16:16, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: Hi, Dmitry. Can you please adds some comments to the code and describe what is going on. On 25.11.16 16:08, dmitry markov wrote: Hello, Could you

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

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8169589 webrev: http://cr.openjdk.java.net/~dmarkov/8169589/webrev.00/ Problem description: Current implementation of CPlatformWindow.orderAboveSiblings() just recursively pops up the windows

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

, dmitry markov wrote: Hi Sergey, I have added some remarks to the code. The updated webrev is located at http://cr.openjdk.java.net/~dmarkov/8169589/webrev.01/ <http://cr.openjdk.java.net/%7Edmarkov/8169589/webrev.01/> Proposed functionality performs ordering operation from the very

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

target.getOwnedWindows() on it, because it can be overridden by the user. You should call "getOwnedWindows_NoClientCode" via accessor, or get a list of child windows via the native api. On 28.11.16 15:12, Alexey Ivanov wrote: Hi Dmitry, Looks fine to me. Regards, Alexey On 28.11.2016 14:53, dmitry ma

Re: [9] Review request for 8165428: Security Warning dialog should be always on the top when multiple applets with APPLICATION_MODAL dialog launched in a browser

Thank you very much, Sergey! Looking for the second +1 from someone else. Thanks, Dmitry On 07/12/2016 19:25, Sergey Bylokhov wrote: Looks fine. 7 дек. 2016 г., в 2:24, Dmitry Markov <dmitry.mar...@oracle.com <mailto:dmitry.mar...@oracle.com>> написал(а): Hi Serg

[9] Review request for 8163889: [macosx] Can't print from browser on Mac OS X

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8163889 webrev: http://cr.openjdk.java.net/~dmarkov/8163889/webrev.00/ Problem description: Several functions inside ImageSurfaceData.m, (e.g. customPixelsFromJava(),

[9] Review request for 8171909: [PIT] on Windows, failure of java/awt/Dialog/DialogAboveFrame/DialogAboveFrameTest.java

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8171909 webrev: http://cr.openjdk.java.net/~dmarkov/8171909/webrev.00/ Problem description: The test displays a frame and a dialog; then it checks the pixel's color to test whether the

Re: [9] Review request for 8165428: Security Warning dialog should be always on the top when multiple applets with APPLICATION_MODAL dialog launched in a browser

Hi Sergey, According to the current implementation we disable a window only when we are going to show a modal dialog. However I agree it is not a good idea to use isEnabled flag for testing whether the window is blocked or not, since such logic is not clear and might be accidentally broken.

[9] Review request for 8165428: Security Warning dialog should be always on the top when multiple applets with APPLICATION_MODAL dialog launched in a browser

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8165428 webrev: http://cr.openjdk.java.net/~dmarkov/8165428/webrev.00/ Problem description: Sometimes the function orderChildWindows() might be called for the window which is blocked

Re: [9] Review request for 8171952: [macosx] AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog test fails as DummyButton on Dialog did not gain focus when clicked.

Thank you very much, Semyon! -Dmitry > On 29 Dec 2016, at 19:13, Semyon Sadetsky <semyon.sadet...@oracle.com> wrote: > > +1 > > --Semyon > > On 29.12.2016 17:47, Dmitry Markov wrote: >> Thank you for review, Sergey! >> Looking for the second +1 from

Re: [9] Review request for 8171952: [macosx] AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog test fails as DummyButton on Dialog did not gain focus when clicked.

Thank you for review, Sergey! Looking for the second +1 from someone else. Thanks in advance, Dmitry > On 29 Dec 2016, at 20:02, Sergey Bylokhov wrote: > > Looks fine. > >> >> Hello, >> >> Could you review a fix for jdk9, please? >> >> bug:

Re: [9] Review request for 8171949: [macosx] AWT_ZoomFrame Automated tests fail with error: The bitwise mask Frame.ICONIFIED is not setwhen the frame is in ICONIFIED state

Thank you, Sergey! Looking for the second +1 from someone else. Thanks, Dmitry > On 28 Dec 2016, at 16:43, Sergey Bylokhov wrote: > > Looks fine. > >> >> Hello, >> >> Could you review a fix for jdk9, please? >> >> bug:

[9] Review request for 8171952: [macosx] AWT_Modality/Automated/ModalExclusion/NoExclusion/ModelessDialog test fails as DummyButton on Dialog did not gain focus when clicked.

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8171952 webrev: http://cr.openjdk.java.net/~dmarkov/8171952/webrev.00/ Problem description: LWCToolkit.getPlatformWindowUnderMouse() looks for a window only at normal window

[9] Review request for 8171949: [macosx] AWT_ZoomFrame Automated tests fail with error: The bitwise mask Frame.ICONIFIED is not setwhen the frame is in ICONIFIED state

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8171949 webrev: http://cr.openjdk.java.net/~dmarkov/8171949/webrev.00/ Problem description: Current implementation of CPlatformWindow.orderAboveSiblings() performs ordering for

[9] Review request for 8176490: [macosx] Sometimes NSWindow.isZoomed hangs

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8176490 webrev: http://cr.openjdk.java.net/~dmarkov/8176490/webrev.00/ Problem description: On OSX AppKit thread and EDT or main application thread might be blocked when a child window

Re: [9] Review request for 8176490: [macosx] Sometimes NSWindow.isZoomed hangs

Thank you, Sergey! Looking for the second +1 from someone else. Thank you in advance, Dmitry On 24/03/2017 21:01, Sergey Bylokhov wrote: Looks fine. Hi Sergey, Thank you for the review. Actually deliverMoveResizeEvent() is always called once a window is displayed. If the window is created

Re: [9] Review request for 8176490: [macosx] Sometimes NSWindow.isZoomed hangs

7SbK10=oXUXbFfbTpz-M7ef_niHcXp1OK4CwY9URWfDWqeeGSc=p4_83q4GHe2-oaP5YEKC2rwF3we54NSigzxwUypoMEw=RlKgriUXqduWXEILzrpT8a8serl1myFuoXjj2IsxLrg= On 27/03/2017 17:24, Alexander Zvegintsev wrote:> Looks fine to me too. Thanks, Alexander. On 27/03/2017 08:35, dmitry markov wrote: Thank you, Sergey! L

Re: JDK 9 b159 - sun.lwawt.macosx.CWrapper$NSWindow.isZoomed never returns

anks Reto -Ursprüngliche Nachricht----- Von: dmitry markov [mailto:dmitry.mar...@oracle.com] Gesendet: Donnerstag, 9. März 2017 08:52 An: Reto Merz Cc: awt-dev@openjdk.java.net Betreff: Re: JDK 9 b159 - sun.lwawt.macosx.CWrapper$NSWindow.isZoomed never returns Hi Reto, I have no seen

[9] Review request for 8173853: IllegalArgumentException in java.awt.image.ReplicateScaleFilter

Hello, Could you review a fix for jdk9, please? bug: https://bugs.openjdk.java.net/browse/JDK-8173853 webrev: http://cr.openjdk.java.net/~dmarkov/8173853/webrev.00/ Problem description: Sometimes XQueryBestCursor may return zero-dimension to the code inside

Re: JDK 9 b159 - sun.lwawt.macosx.CWrapper$NSWindow.isZoomed never returns

Hi Reto, I have no seen such hang before. Most likely this is a new issue. Could you provide us with a test case, (i.e. reproducer), please? Once we have a reproducer, I will open a bug for this. Thanks, Dmitry On 07/03/2017 19:52, Reto Merz wrote: Hi, We have a integration test which hangs

Re: [9] Review request for 8173853: IllegalArgumentException in java.awt.image.ReplicateScaleFilter

Hi Sergey, I ran JCK tests and didn't observe any problems introduced by the fix. Thanks, Dmitry On 06/03/2017 22:24, Sergey Bylokhov wrote: Ok, But will it be possible to use this custom cursor? For example according to the spec: * @param hotSpot the X and Y of the large cursor's hot

Re: [9] Review request for 8173853: IllegalArgumentException in java.awt.image.ReplicateScaleFilter

Hi Sergey, In my opinion if zero size is returned as a result of getBestCursorsize() invocation, the cursor should have initial size defined by the parameter of its constructor. I am sorry, but it will look very odd especially for end user, if we silently change an original cursor's size to

[10] Review request for 8177414: Missing key events on Mac Os

Hello, Could you review a fix for jdk10, please? bug: https://bugs.openjdk.java.net/browse/JDK-8177414 webrev: http://cr.openjdk.java.net/~dmarkov/8177414/webrev.00/ Problem description: On OSX KEY_TYPED and KEY_PRESSED events might be lost if the input method such as ‘British’, ‘US

Re: [10] Review request for 8177414: Missing key events on Mac Os

Thank you, Sergey! Looking for the second +1 from someone else. Thanks, Dmitry > On 4 Aug 2017, at 01:07, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > > Looks fine. > > On 02.08.2017 7:26, Dmitry Markov wrote: >> Hello, >> Could you review a fix fo

Re: [10] Review request for 8177414: Missing key events on Mac Os

Thank you very much, Phil! Regards, Dmitry > On 4 Aug 2017, at 15:00, Philip Race <philip.r...@oracle.com> wrote: > > Approved. > > -phil. > > On 8/4/17, 6:58 AM, Dmitry Markov wrote: >> Thank you, Sergey! >> >> Looking for the second +1 from so

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

Hi Sergey, The fix looks good to me. Thanks, Dmitry > On 14 Sep 2017, at 23:46, Sergey Bylokhov wrote: > > Hello, > Please review the fix for jdk10. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8186559 > Webrev can be found at:

[10] Review request for 8155197: Focus transition issue

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.00/ Problem description: Currently we restore focus synchronously to a component if the window (which contains it) owns the

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

Hi Sergey, The fix still looks good for me. Thanks, Dmitry > On 18 Sep 2017, at 23:04, 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

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

ible and focusable, isn't it? > > On 10/3/17 08:23, Dmitry Markov wrote: >> Hi Semyon, >> I have updated the fix based on your suggestion. The new version is located >> at http://cr.openjdk.java.net/~dmarkov/8155197/webrev.02/ >> <http://cr.openjdk.java.net/~dmarko

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

may become null while the next component in container > traversal order is expected to have the input focus. > --Semyon > > On 10/04/2017 03:25 AM, Dmitry Markov wrote: >> Hi Sergey, >> >> Good catch! >> Actually we check restoreFocusTo before its usage,

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

Hi Sergey, > On 4 Oct 2017, at 19:27, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > > On 10/4/17 03:25, Dmitry Markov wrote: >> Good catch! >> Actually we check restoreFocusTo before its usage, (i.e. we compare >> restoreFocusTo with most resent focus

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

Hi Semyon, > On 26 Sep 2017, at 23:46, Semyon Sadetsky <semyon.sadet...@oracle.com> wrote: > > Hi Dmitry, > > On 9/26/2017 1:56 AM, Dmitry Markov wrote: >> Hi Semyon, >> >> Please find my answer inline. >> >> Thanks, >> Dmitry &g

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

ars on the screen for a longer while, the test does not fail >> either. >> >> >> Regards, >> Alexey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8155197 >> <https://bugs.openjdk.java.net/browse/JDK-8155197> >> >> On 26/09/

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

Hi Semyon, > On 28 Sep 2017, at 18:34, Semyon Sadetsky <semyon.sadet...@oracle.com> wrote: > > Hi Dmitry and Alexey, > > On 9/28/2017 8:14 AM, Dmitry Markov wrote: >> I have updated the regression test for the fix. The new version is located >> at http://cr.

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

Hi Semyon, I have updated the fix based on your suggestion. The new version is located at http://cr.openjdk.java.net/~dmarkov/8155197/webrev.02/ Also I slightly modified the test to simplify it. Thanks, Dmitry > On 2 Oct 2017, at 18:32,

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

Hi Semyon, Please find my answer inline. Thanks, Dmitry > On 25 Sep 2017, at 22:26, Semyon Sadetsky <semyon.sadet...@oracle.com> wrote: > > Hi Dmitry, > > > On 09/25/2017 01:09 PM, Dmitry Markov wrote: >> Hi Semyon, >> >> This issue and th

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

by the changes introduced by 8139218 and 8159432. Thanks, Dmitry > On 25 Sep 2017, at 15:58, Semyon Sadetsky <semyon.sadet...@oracle.com> wrote: > > Hi Dmitry, > > This issue was already fixed in 9. See 8139218 & 8159432. > > --Semyon > > > On 09/23/2017

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

> but such rare scenario can be easily workarounded on a user side by calling > setLocation() right after setVisible() call. > > So I would prefer to use addChildWindow() to make this fix as simple as > possible. > > > Thanks, > Alexander. > >

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

Hi Semyon, > On 5 Oct 2017, at 17:13, Semyon Sadetsky <semyon.sadet...@oracle.com> wrote: > > Hi Dmitriy, > > On 10/05/2017 07:25 AM, Dmitry Markov wrote: >> Hi Semyon, >> >> Actually the most recent focus owner is updated during invocation of >>

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

Hi Semyon, Looks good to me. Thanks, Dmitry > On 6 Oct 2017, at 20:47, Semyon Sadetsky wrote: > > Hello, > > Please review fix for JDK10: > > bug: https://bugs.openjdk.java.net/browse/JDK-8182638 > > webrev:

[10] RFR 8193435: Remove pre-1.2 SecurityManager text from java.awt.Toolkit

Hello, Could you review a fix for jdk10, please? bug: https://bugs.openjdk.java.net/browse/JDK-8193435 webrev: http://cr.openjdk.java.net/~dmarkov/8193435/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8193709 Problem

Re: [10] Review request for 8154405: AccessControlException by URLPermission check

/8154405/webrev.00/) which is already approved on this list. Sean, Could you take a look at http://cr.openjdk.java.net/~dmarkov/8154405/webrev.00/ , please? Thank you in advance, Dmitry > On 8 Dec 2017, at 11:19, Dmitry Markov <dmitry.mar...@oracle.com> wrote: > > Reminder. Coul

Re: [10] Review request for 8154405: AccessControlException by URLPermission check

Thank you, Sergey! Shall I create a CSR for this? Thanks, Dmitry > On 17 Nov 2017, at 19:34, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > > Looks fine. > > On 17/11/2017 06:38, Dmitry Markov wrote: >> Hello, >> Could you review a fix

Re: [10] Review request for 8154405: AccessControlException by URLPermission check

I have created the following one https://bugs.openjdk.java.net/browse/JDK-8191531 <https://bugs.openjdk.java.net/browse/JDK-8191531> Thanks, Dmitry > On 17 Nov 2017, at 22:10, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > > On 17/11/2017 12:28, Dmitry Markov wrote:

[10] Review request for 8154405: AccessControlException by URLPermission check

Hello, Could you review a fix for jdk10, please? bug: https://bugs.openjdk.java.net/browse/JDK-8154405 webrev: http://cr.openjdk.java.net/~dmarkov/8154405/webrev.00/ Problem description: The current implementation of Toolkit.getImage(URL url) and Toolkit.createImage(URL url) uses

Re: [10] Review Request 8190230: [macosx] Order of overlapping of modal dialogs is wrong

Hi Semyon, The fix looks good to me. I have only a minor remark regarding the test. It might be reasonable to use Util.testPixelColor() from regtesthelpers package instead of Robot.getPixelColor(). However it is up to you and you may keep it as is. Thanks, Dmitry > On 31 Oct 2017, at 15:05,

Re: [10] Review request for 8154405: AccessControlException by URLPermission check

tructor of URLImageSource. Now if security check of > URLPermission is failed we will check the corresponding SocketPermission. > - Added regression test. > > Thanks, > Dmitry > >> On 18 Nov 2017, at 15:30, Dmitry Markov <dmitry.mar...@oracle.com >> <mailto

Re: [10] Review request for 8154405: AccessControlException by URLPermission check

18 Nov 2017, at 15:30, Dmitry Markov <dmitry.mar...@oracle.com> wrote: > > I have created the following one > https://bugs.openjdk.java.net/browse/JDK-8191531 > <https://bugs.openjdk.java.net/browse/JDK-8191531> > > Thanks, > Dmitry >> On 17 Nov 201

Re: [11] Review Request: 8201364 [macosx] Component.getLocation() gives inconsistent coordinate for a component at (0, 0)

Hi Sergey, According to your fix replacSurfaceData() and updateMinimumSize() are invoked only if the graphics device has been changed or the peer has been resized: > 734 if (pResized || isNewDevice) { > 735 replaceSurfaceData(); > 736 updateMinimumSize(); >

Re: [11] Review Request: 8201364 [macosx] Component.getLocation() gives inconsistent coordinate for a component at (0, 0)

> On 17 May 2018, at 19:25, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote: > > On 17/05/2018 02:05, Dmitry Markov wrote: >> Hi Sergey, >> According to your fix replacSurfaceData() and updateMinimumSize() are >> invoked only if the graphics device has

  1   2   3   >