Re: RFR: 8272806: [macOS] "Apple AWT Internal Exception" when input method is changed

On Sun, 22 Aug 2021 19:46:49 GMT, Phil Race wrote: > There's a long eval in the bug report : > https://bugs.openjdk.java.net/browse/JDK-8272806 but here's the summary > > When focus is lost by the app a message is sent down to native setting a > native reference to the input method to null >

Re: RFR: 8264344: Outdated links in JavaComponentAccessibility.m

On Mon, 29 Mar 2021 08:31:48 GMT, Alexander Zuev wrote: > 8264344: Outdated links in JavaComponentAccessibility.m Marked as reviewed by dmarkov (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/3240

Re: RFR: 8263490: [macos] Crash occurs on JPasswordField with activated InputMethod

On Fri, 12 Mar 2021 08:16:09 GMT, Toshio Nakamura wrote: > Hi, > Please review the fix for the issue of JPasswordField and activated > InputMethod on macOS. > I don't think this condition is usual, but I'd like to avoid crash. > > It needs two additional checks in "AWTView >

Integrated: 8262446: DragAndDrop hangs on Windows

On Thu, 4 Mar 2021 10:36:56 GMT, Dmitry Markov wrote: > The IME functions and the DND operation must be executed on the toolkit > thread. If the DND operation is in progress, the IME API is invoked via > SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. Th

Re: RFR: 8262446: DragAndDrop hangs on Windows

On Thu, 4 Mar 2021 10:36:56 GMT, Dmitry Markov wrote: > The IME functions and the DND operation must be executed on the toolkit > thread. If the DND operation is in progress, the IME API is invoked via > SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. Th

Re: RFR: 8262446: DragAndDrop hangs on Windows [v4]

ate DND operation between Java and native app. > > Testing: > mach5 green Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision: Update copyright - Changes: - all: https://git.openjdk.java.net/jdk/pull/2825/files

Re: RFR: 8262446: DragAndDrop hangs on Windows [v3]

ate DND operation between Java and native app. > > Testing: > mach5 green Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision: Remove flag setting from DragOver - Changes: - all: https://git.openjdk.java

Re: RFR: 8262446: DragAndDrop hangs on Windows [v2]

On Fri, 5 Mar 2021 17:01:41 GMT, Alexey Ivanov wrote: >> Dmitry Markov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> reuse isInDoDragDropLoop > > src/java.desktop/windows/native/libawt/windows/awt

Re: RFR: 8262446: DragAndDrop hangs on Windows [v2]

On Fri, 5 Mar 2021 12:53:00 GMT, Dmitry Markov wrote: >>> Why we cannot reuse the old flag? "isInDoDragDropLoop"? I think the >>> Robot.waitForIdle() will hang if isInDoDragDropLoop is not set to true >>> while dragging something from the native app. &g

Re: RFR: 8262446: DragAndDrop hangs on Windows [v2]

On Fri, 5 Mar 2021 12:51:15 GMT, Dmitry Markov wrote: >> Why we cannot reuse the old flag? "isInDoDragDropLoop"? I think the >> Robot.waitForIdle() will hang if isInDoDragDropLoop is not set to true while >> dragging something from the native app. > >

Re: RFR: 8262446: DragAndDrop hangs on Windows [v2]

ate DND operation between Java and native app. > > Testing: > mach5 green Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision: reuse isInDoDragDropLoop - Changes: - all: https://git.openjdk.java

Re: RFR: 8262446: DragAndDrop hangs on Windows [v2]

On Fri, 5 Mar 2021 01:34:04 GMT, Sergey Bylokhov wrote: > Why we cannot reuse the old flag? "isInDoDragDropLoop"? I think the > Robot.waitForIdle() will hang if isInDoDragDropLoop is not set to true while > dragging something from the native app. Initially I didn’t want to touch that flag but

RFR: 8262446: DragAndDrop hangs on Windows

The IME functions and the DND operation must be executed on the toolkit thread. If the DND operation is in progress, the IME API is invoked via SendMessage() call inside InvokeInputMethodFunction() to avoid a hang. The flag isInDoDragDropLoop indicates whether the DND takes place or not. The

Integrated: 8261231: Windows IME was disabled after DnD operation

On Sun, 7 Feb 2021 08:29:57 GMT, Dmitry Markov wrote: > The function InvokeInputMethodFunction() is responsible for invocation of IME > API. Typically it uses PostMessage() to execute corresponding IME function on > the toolkit thread but if DnD operation takes place SendMessage(

Re: RFR: 8261231: Windows IME was disabled after DnD operation

On Mon, 8 Feb 2021 16:51:21 GMT, Alexander Zuev wrote: > Change looks good and i haven't found any side-effects during testing. Could > you please add the label to the bug noting reason for absence of the > regression test, like noreg-hard or something? Thank you for the review. I have added

RFR: 8261231: Windows IME was disabled after DnD operation

The function InvokeInputMethodFunction() is responsible for invocation of IME API. Typically it uses PostMessage() to execute corresponding IME function on the toolkit thread but if DnD operation takes place SendMessage() is used. The state of m_inputMethodWaitEvent event object remains

Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 [v2]

On Thu, 21 Jan 2021 21:34:25 GMT, Alexey Ivanov wrote: >> Dmitry Markov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use endComposition() instead of endCompositionNative() > > Marked as reviewe

Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10

On Thu, 21 Jan 2021 19:25:16 GMT, Alexey Ivanov wrote: > I admit I am even more confused now. To me, the description in the comment > above is nearly the same as in [JBS >

Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10

On Thu, 21 Jan 2021 14:18:43 GMT, Alexey Ivanov wrote: > > Now we will commit the composition string if there is an active client. > > That changes eliminates the issue described in JDK-8258805. Also the > > behaviour of AWTTextTest1 is the same as it used to be on the previous > > versions

Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10

On Wed, 20 Jan 2021 12:28:36 GMT, Alexey Ivanov wrote: >>> > Fix: >>> > It is necessary to take care of unconfirmed composition string once the >>> > IME is going to be disabled. >>> >>> The fix commits the unconfirmed composition string. Committing is better >>> than discarding. Is it

Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10 [v2]

be disabled. > > Testing: > All our automated regression and JCK tests passed with the proposed change. Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision: Use endComposition() instead of endCompositionNative() - C

Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10

On Wed, 20 Jan 2021 07:35:18 GMT, Ichiroh Takiguchi wrote: >> How do the native components work in that case like awt textarea or external >> apps like notepad? > >> How do the native components work in that case like awt textarea or external >> apps like notepad? > > I tested

Re: RFR: 8258805: Japanese characters not entered by mouse click on Windows 10

On Tue, 19 Jan 2021 12:44:22 GMT, Alexey Ivanov wrote: > > Fix: > > It is necessary to take care of unconfirmed composition string once the IME > > is going to be disabled. > > The fix commits the unconfirmed composition string. Committing is better than > discarding. Is it possible to

Re: [EXTERNAL] RFR: 8258805: Japanese characters not entered by mouse click on Windows 10

e, so I don't know the details. > I think the current code can change the candidate string after getting the > focus. > If possible, could you show me the test instructions ? > > Thanks, > Ichiroh Takiguchi > > On 2021-01-19 20:16, Dmitry Markov wrote: >> Problem descri

RFR: 8258805: Japanese characters not entered by mouse click on Windows 10

Problem description: The IME behaviour has changed starting from recent Windows 10 builds. In particular if the complex characters (Japanese, Chinese, etc.) are entered to some component and the focus is transferred to another component (which does not support the IM) the IM is disabled and the

Re: [16] RFR 8252470: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails on Windows

Aug 2020, at 21:00, Philip Race wrote: > > Looks Ok to me but please confirm that all related tests pass. > > -phil. > > On 8/28/20, 12:54 PM, Dmitry Markov wrote: >> >> Hello, >> >> Could you review the fix for JDK 16, please? >> >> b

[16] RFR 8252470: java/awt/dnd/DisposeFrameOnDragCrash/DisposeFrameOnDragTest.java fails on Windows

Hello, Could you review the fix for JDK 16, please? bug: https://bugs.openjdk.java.net/browse/JDK-8252470 webrev: http://cr.openjdk.java.net/~dmarkov/8252470/webrev.00/

Re: [16] RFR 8232114: JVM crashed at imjpapi.dll in native code

t; The fix looks good. Thank you for taking into account my suggestions. > > Thank you, > Anton > > On 24/08/2020 10:10, Dmitry Markov wrote: >> Hi Anton, >> >> Thank you for review. I have updated the fix based on your suggestions: >> - Modified t

Re: [16] RFR 8232114: JVM crashed at imjpapi.dll in native code

MethodData; > } > return 0; > > 2) In "AwtToolkit::WndProc" function in the code handling the messages: > "WM_AWT_HANDLE_NATIVE_IME_EVENT", "WM_AWT_ACTIVATEKEYBOARDLAYOUT", > "WM_AWT_OPENCANDIDATEWINDOW" I do not find calls to "Imm*" system f

Re: [16] RFR 8232114: JVM crashed at imjpapi.dll in native code

Thank you, Sergey! Looking for one more "+1”. Any volunteers? Regards, Dmitry > On 17 Aug 2020, at 21:06, Sergey Bylokhov wrote: > > Looks fine. > > On 17.08.2020 02:32, Dmitry Markov wrote: >> Hi Sergey, >> I have added that information to InvokeInputMethodFun

Re: [16] RFR 8232114: JVM crashed at imjpapi.dll in native code

ov wrote: > > On 12.08.2020 05:09, Dmitry Markov wrote: >> TranslateMessage() does not invoke PeekMessage(). In our case >> TranslateMessage() is called by AWT. IME functionality may call >> PeekMessage() during TranslateMessage() execution. However that >> PeekMessag

Re: [16] RFR 8232114: JVM crashed at imjpapi.dll in native code

hov wrote: > > Hi, Dmitry. > > On 11.08.2020 01:07, Dmitry Markov wrote: >> Problem description: >> The root cause of the crash is the lack of synchronisation in imjpapi.dll. >> In particular when IME messages are processed in the message loop and >> another

[16] RFR 8232114: JVM crashed at imjpapi.dll in native code

Hello, Could you review the fix for JDK 16, please? bug: https://bugs.openjdk.java.net/browse/JDK-8232114 webrev: http://cr.openjdk.java.net/~dmarkov/8232114/webrev.00/

Re: RFR: 8078228 Default file manager and web browser didn't launch and got SecurityException

Hi Sergey, The fix looks good to me. One minor remark: shall we update "@bug” section with this bug id in the test? I do not need the new web rev with this change. Regards, Dmitry > On 5 Aug 2020, at 07:31, Sergey Bylokhov wrote: > > Hello. > Please review the fix for jdk/client. > > Bug:

Re: [15] Review Request: 8237049 Rollback the workaround for JDK-4533057

Hi Sergey, The changes look good to me. Thanks, Dmitry > On 19 Jan 2020, at 23:18, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 15. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8237049 > Fix: http://cr.openjdk.java.net/~serb/8237049/webrev.00 > > Long-time ago we

Re: [15] Review request for 8230926: [macosx] Two apostrophes are entered instead of one with "U.S. International - PC" layout

erKeys". > > Therefore I suggest to stay with the first fix version. Dmitry, what is your > opinion about this suggestion? > > Thank you, > Anton > > On 07/01/2020 13:07, Dmitry Markov wrote: >> Hi Anton, >> >> The fix looks good to me. >>

Re: [15] Review request for 8230926: [macosx] Two apostrophes are entered instead of one with "U.S. International - PC" layout

Hi Anton, The fix looks good to me. Just a minor remark: I would recommend using unicode instead of character during array definition inside isCharModifierKeyInUSInternationalPC() method, (i.e. replace ‘\’’ with ‘u\0027’ for apostrophe and so on). That’s quite trivial change and I don’t need

Re: [14] Review Request: 8236545 Compilation error in mach5 java/awt/FileDialog/MacOSGoToFolderCrash.java

Looks good to me. Thanks, Dmitry > On 30 Dec 2019, at 23:07, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 14. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8236545 > Fix: http://cr.openjdk.java.net/~serb/8236545/webrev.00 > > This test may fail due to compilation

Re: [14] Review Request: 8235739 Rare NPE at WComponentPeer.getGraphics()

+1 Thanks, Dmitry > On 13 Dec 2019, at 19:12, Alexey Ivanov wrote: > > On 12/12/2019 23:14, Sergey Bylokhov wrote: >> On 12/12/19 7:58 am, Alexey Ivanov wrote: >>> Shall we return null if wpeer is already null? >>> Rather than falling back to this.surfaceData. >> >> wpeer is a peer of the

Re: [14] Review Request: 8235638 NPE in LWWindowPeer.getOnscreenGraphics()

Sadhukhan wrote: >>> >>> Hi Dmitry, >>> >>> It seems that webrev is not accessible anymore, but I guess it will be good >>> if both the fix can be clubbed together. >>> >>> Regards >>> >>> Prasanta >>> &

Re: [14] Review Request: 8235638 NPE in LWWindowPeer.getOnscreenGraphics()

Hi Prasanta, I guess the NPE, you observed, is already addressed by https://bugs.openjdk.java.net/browse/JDK-8235739 (which is on review now, see http://mail.openjdk.java.net/pipermail/awt-dev/2019-December/015621.html

Re: [14] Review Request: 8234522 [macos] Crash with use of native file dialog

p. > > On 12/10/19 4:03 am, Dmitry Markov wrote: >> Hi Sergey, >> The changes look OK, but I have a few remarks. I would recommend using >> NSEventTypeApplicationDefined due to deprecation of NSApplicationDefined. >> Also it would be good to add some kind of summa

Re: [14] Review Request: 8234522 [macos] Crash with use of native file dialog

Hi Sergey, The changes look OK, but I have a few remarks. I would recommend using NSEventTypeApplicationDefined due to deprecation of NSApplicationDefined. Also it would be good to add some kind of summary to the regression test. I do not need a new webrev with suggested changes. Thanks,

Re: RFC: JDK-8231991: Mouse wheel change focus on awt/swing windows

Hi Mario, The fix looks good to me. Thanks, Dmitry > On 11 Nov 2019, at 09:42, Mario Torre wrote: > > On Thu, 2019-10-31 at 12:00 +0100, Mario Torre wrote: >> On Wed, 2019-10-30 at 15:45 -0700, Sergey Bylokhov wrote: >>> Looks fine. >> >> Thanks! >> >> I believe I still need a second

Re: [14] RFR JDK-8233703:java/awt/Frame/FrameLocation.java fails on mac

gt; > Hi Dmitry. > > My ubuntu18.04 is running on Gnome and I think mach5 linux is also running > same, I do not think mach5 linux system is running on Compiz window manager, > where the issue was seen earlier. > > Regards > Prasanta > On 06-Nov-19 8:29 PM, Dmitry Marko

Re: [14] RFR JDK-8233703:java/awt/Frame/FrameLocation.java fails on mac

makes me think > it's a test issue. >> Regards >> Prasanta >> On 06-Nov-19 7:13 PM, Dmitry Markov wrote: >>> Hi Prasanta, >>> >>> If I got it right, we might not have enough time to show frame on the >>> screen without sleep() invoca

Re: [14] RFR JDK-8233703:java/awt/Frame/FrameLocation.java fails on mac

Hi Prasanta, If I got it right, we might not have enough time to show frame on the screen without sleep() invocation. As a result incorrect frame location will be retrieved. So I think we should NOT get rid of sleep() call here. Also it appears that the problem is not in the test at all.

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

Thank you, Magnus! Dmitry > On 4 Nov 2019, at 10:24, Magnus Ihse Bursie > wrote: > > > > On 2019-11-03 16:38, Dmitry Markov wrote: >> Alexey and Sergey, thank you for the approval! >> I wonder whether it is enough or I need one more “+1” from build-folk. > Y

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

The changes look good to me. >> On 01/11/2019 13:09, Dmitry Markov wrote: >>> Hi Alexey, >>> >>> I have updated the fix. Please find the new version here: >>> http://cr.openjdk.java.net/~dmarkov/8232880/webrev.03/ >>> >>> Thanks, >>&g

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

ecommend adding quotes around the option to look for: > 448 in the right-side pane look for "Turn off Windows key hotkeys" and double > click on it; > > Consider adding an empty line before this line > 450 Note: restart is required to make the settings take effect. > t

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

e. no backticks. > > (For my understanding, "Turn keyboard access on or off" turns off only one > specific shortcut, i.e. Ctrl+F1?) Yes, that’s right. I have added clarification to the doc. > > > Regards, > Alexey > > On 28/10/2019 17:23, Dmitry Markov

Re: RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

an provide CTRL+F1 which is used > > > On 10/25/19 3:27 am, Dmitry Markov wrote: >> Hello, >> Could you review the fix for jdk14, please? >> bug: https://bugs.openjdk.java.net/browse/JDK-8232880 >> <https://bugs.openjdk.java.net/browse/JDK-8232880>

RFR 8232880: Update test documentation with additional settings for client UI tooltip tests

Hello, Could you review the fix for jdk14, please? bug: https://bugs.openjdk.java.net/browse/JDK-8232880 webrev: http://cr.openjdk.java.net/~dmarkov/8232880/webrev.00/

Re: [14] Review Request: 7124404 [macosx] no awt.multiClickInterval desktop property

Hi Sergey, The fix looks fine. Just a minor remark - the function description in LWCToolkit.m says: “Signature: ()Z “; but the function returns int and not boolean. I don’t need a new webrev for that correction. Thanks, Dmitry > On 29 Sep 2019, at 06:57, Sergey Bylokhov wrote: > > Hello. >

Re: [14] RFR 8230782: Robot.createScreenCapture() fails if “awt.robot.gtk” is set to false

a regression test. > There are no related keywords on the bug .. > > -phil. > > > On 9/19/19 9:12 AM, Dmitry Markov wrote: >> Hello, >> >> Could you review a fix for jdk14, please? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8230782 >

[14] RFR 8230782: Robot.createScreenCapture() fails if “awt.robot.gtk” is set to false

Hello, Could you review a fix for jdk14, please? bug: https://bugs.openjdk.java.net/browse/JDK-8230782 webrev: http://cr.openjdk.java.net/~dmarkov/8230782/webrev.00/ Problem description: After integration of JDK-8210776 [1] we started to use malloc() function for allocation of XColor array

Re: [14] RFR JDK-8225805 - Java Access Bridge does not close the logger

Hi Pankaj, The fix looks good to me. Thanks, Dmitry > On 10 Sep 2019, at 11:06, Pankaj Bansal wrote: > > Hi All, > > Please review the following fix for jdk14. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8225805 > > > webrev >

Re: [14] Review Request: 8229515 [macos] access to window property of NSView on wrong thread

Hi Sergey, The fix looks good to me. Thanks, Dmitry > On 30 Aug 2019, at 21:59, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 14. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229515 > Fix: http://cr.openjdk.java.net/~serb/8229515/webrev.00 > > The access to the

Re: [13] Review Request: 8144125 [macOS] java/awt/event/ComponentEvent/MovedResizedTwiceTest/MovedResizedTwiceTest.java failed automatically

Hi Sergey, The fix looks fine. Shall we add ‘headful’ key to the test? Thanks, Dmitry > On 29 Apr 2019, at 11:27, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8144125 > Fix:

Re: [13] Review Request: 7141393 [macosx] CARemoteLayer code refactoring and unit test

Hi Sergey, The changes look good to me. Thanks, Dmitry > On 8 May 2019, at 07:54, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-7141393 > Fix: http://cr.openjdk.java.net/~serb/7141393/webrev.00 > > AWT on macOS

Re: [13] Review Request: 8214046 [macosx] Undecorated Frame does not Iconify when set to

Hi Sergey, The fix looks good to me. Thanks, Dmitry > On 15 Apr 2019, at 05:13, Sergey Bylokhov wrote: > > Hello. > Please review the fix for JDK 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8214046 > Fix: http://cr.openjdk.java.net/~serb/8214046/webrev.00 > > After we upgrade our

Re: [13] Review Request: 8219504 Test for JDK-8211435 can be run on all platforms

Hi Sergey, The fix looks good to me. Thanks, Dmitry > On 7 Mar 2019, at 06:59, Sergey Bylokhov wrote: > > Thank you for review! > Looking for the second +1 from someone else. > > On 20/02/2019 22:20, Krishna Addepalli wrote: >> +1 >> Krishna >> -Original Message- >> From: Sergey

Re: [13] RFR 8214109: XToolkit is not correctly displayed color on 16-bit high color setting

That’s right. I ran corresponding regression tests on Ubuntu and I didn’t see any issues. Thanks, Dmitry > On 23 Feb 2019, at 23:43, Philip Race wrote: > > This doesn't regress anything with the OGL pipeline on Linux, does it ? > > -phil. > > On 2/18/19, 12:23 AM

Re: [13] RFR 8214109: XToolkit is not correctly displayed color on 16-bit high color setting

Thank you, Sergey! Looking for the second +1 from someone else. Dmitry > On 16 Feb 2019, at 02:10, Sergey Bylokhov wrote: > > Looks fine. > > On 15/02/2019 04:06, Dmitry Markov wrote: >> Hi Sergey, >> I think we can just replace ColorModel based cal

Re: [13] RFR 8214109: XToolkit is not correctly displayed color on 16-bit high color setting

/webrev.01/ <http://cr.openjdk.java.net/~dmarkov/8214109/webrev.01/> Also I ran all regression tests and didn’t observe any new failures. Thanks, Dmitry > On 31 Jan 2019, at 22:25, Sergey Bylokhov wrote: > > Hi, Dmitry. > On 30/01/2019 05:02, Dmitry Markov wrote: > >>

[13] RFR 8214109: XToolkit is not correctly displayed color on 16-bit high color setting

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

Re: [13] Review Request: 8215756 Memory leaks in the AWT on macOS

, retain) JNFWeakJObjectWrapper *javaPlatformWindow; > > So it is not necessary to release it manually and just assigned to nil is > enough. > > http://cr.openjdk.java.net/~serb/8215756/webrev.01/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m.sdiff.html > > >

Re: [13] Review Request: 8215756 Memory leaks in the AWT on macOS

Hi Sergey, The fix looks good to me. Thanks, Dmitry > On 21 Dec 2018, at 00:20, Sergey Bylokhov wrote: > > Hello. > Please review the fix for jdk 13. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215756 > Webrev: http://cr.openjdk.java.net/~serb/8215756/webrev.00 > > Two memory leaks

Re: [12] Review Request: 8215200 IllegalArgumentException in sun.lwawt.macosx.CPlatformWindow

Hi Sergey, The fix looks good. Thanks, Dmitry > On 14 Dec 2018, at 07:32, Sergey Bylokhov wrote: > > Hello. > Please review the fix for jdk 12. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215200 > Webrev: http://cr.openjdk.java.net/~serb/8215200/webrev.00 > > In the fix for

[12] RFR 8213583: Error while opening the JFileChooser when desktop contains shortcuts pointing to deleted files

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

Re: [12] RFR 8213983: [macosx] Keyboard shortcut “cmd +`” stops working properly if popup window is displayed

ttp://cr.openjdk.java.net/~dmarkov/8213983/webrev.02/> Could you review the new version, please? Thanks, Dmitry > On 21 Nov 2018, at 23:22, Sergey Bylokhov wrote: > > On 21/11/2018 12:51, Dmitry Markov wrote: >> When we are going to display the popup, all related windows, (i.

Re: [12] RFR 8213983: [macosx] Keyboard shortcut “cmd +`” stops working properly if popup window is displayed

level which is located above other windows. Thanks, Dmitry > On 21 Nov 2018, at 20:36, Sergey Bylokhov wrote: > > Hi, Dmitry. > On 21/11/2018 08:40, Dmitry Markov wrote: >> On OS X the keyboard shortcut “cmd +`” stops working properly if a popup >> window is displayed.

Re: [12] RFR 8213983: [macosx] Keyboard shortcut “cmd +`” stops working properly if popup window is displayed

be only one. > If I understand correctly, if a modal dialog/any other child window has a > ComboBox component in it, then PopupMenu will be an additional window, and > the length may not necessarily be equal to one. > > Thanks, > Krishna > >> On 21-Nov-2018, at 10:10 PM,

[12] RFR 8213983: [macosx] Keyboard shortcut “cmd +`” stops working properly if popup window is displayed

Hello, Could you review a fix for jdk12, please? bug: https://bugs.openjdk.java.net/browse/JDK-8213983 webrev: http://cr.openjdk.java.net/~dmarkov/8213983/webrev.00/ On

Re: RFR 8213532: add missing LocalFree calls after using FormatMessage(A) [windows]

Hi Matthias, The fix looks good. Thanks, Dmitry > On 14 Nov 2018, at 07:48, Baesken, Matthias wrote: > > Hi Sergey, thanks for the review ! > > Could I have a second review please, before I push the change ? > > Best regards, Matthias > > >> -Original Message- >> From: Sergey

Re: Swing dev>[12] Review request for JDK-8189253: [macos] JPopupMenu is inadvertently shown when using setComponentPopupMenu

. If the windows (parent and child) are created on same >> screen then addChildWindow is used to order child window on top of parent >> window. And orderWindow is used for the other case when windows are created >> on different screens. >> >> Please review the fix: &

Re: [12] Review request for JDK-8208543: [macos] Support for apple.awt.documentModalSheet incomplete

dialog.add(new JLabel("Hello world!")); >dialog.pack(); >dialog.setVisible(true); > ===> > > On 30/10/2018 04:16, Krishna Addepalli wrote: >> +1 >> Krishna >> -Original Message- >> From: Dmitry Markov >> Sent: Friday,

Re: [12] Review request for JDK-8208543: [macos] Support for apple.awt.documentModalSheet incomplete

3/webrev.02/ > <http://cr.openjdk.java.net/%7Emhalder/8208543/webrev.02/> > > Regards, > Manajit > > > > On 25/10/18 7:18 PM, Dmitry Markov wrote: >> Hi Manajit, >> >> Currently the test is marked as ‘passed’ if timeout takes place. I think we >>

Re: [12] Review request for JDK-8208543: [macos] Support for apple.awt.documentModalSheet incomplete

Test case was modified to add a case for the failed scenario "Dialog > without owner". > > Please review the modified webrev: > http://cr.openjdk.java.net/~mhalder/8208543/webrev.01/ > <http://cr.openjdk.java.net/%7Emhalder/8208543/webrev.01/> > > Regards

Re: [12] Review Request: 8211435 Exception in thread "AWT-EventQueue-1" java.lang.IllegalArgumentException: null source

Hi Sergey, The fix looks good to me. I think you can make the test generic once JDK-8204142 is fixed. Thanks, Dmitry > On 24 Oct 2018, at 22:31, Sergey Bylokhov wrote: > > Hello. > Please review the fix for jdk 12. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8211435 > Webrev:

Re: [12] Review request for JDK-8208543: [macos] Support for apple.awt.documentModalSheet incomplete

Hi Manajit, There is an inconsistency between the proposed implementation and Apple JDK: if the property applied to the dialog which does not have an owner on the build with your changes it appears as sheet, but on Apple JDK it appears as a window. I think every frame/dialog inside dispose()

[8u] RFR: 8210891: Remove unused extutil.h from JDK8u sources

Hello, Could you review the following fix, please? bug: https://bugs.openjdk.java.net/browse/JDK-8210891 webrev: http://cr.openjdk.java.net/~dmarkov/8210891/webrev.00/

Re: RFR: 8210886: Remove references in xwindows.md to non-existent files.

Hi Phil, The changes look good to me. Thanks, Dmitry > On 26 Sep 2018, at 19:23, Phil Race wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8210886 > webrev: http://cr.openjdk.java.net/~prr/8210886/ > > the legal file xwindows.md gives attribution for several source files > from the

Re: [12] Review Request: 8210286 Drop of sun.awt.HToolkit class

Looks good to me. Thanks, Dmitry > On 21 Sep 2018, at 22:43, Sergey Bylokhov wrote: > > Any volunteers for review? =) > > On 03/09/2018 16:36, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk 12. >> This class was used as a headless toolkit for embedded purposes. >> - It was

Re: RFR: 8210866: Remove HPKeysym.h from JDK sources

The changes look good to me. Thanks, Dmitry > On 18 Sep 2018, at 22:49, Phil Race wrote: > > Thanks, > > However I also need to remove the now obsolete > comment which explained why we had our own copy .. > http://cr.openjdk.java.net/~prr/8210866.1 > > -phil. > > On 09/18/2018 01:14 PM,

Re: [12] RFR JDK-8191178:[macos] Problem with input of yen symbol

& (codePoint <= 0xFFEF) > right? > > Regards > Prasanta > On 17-Sep-18 9:22 PM, Dmitry Markov wrote: >> Hi Prasanta, >> >> I think it would be wise to generate InputMethodEvent for ‘Fullwidth >> currency symbols’, as well. >> >> Thanks, >

Re: [12] RFR JDK-8191178:[macos] Problem with input of yen symbol

Hi Prasanta, I think it would be wise to generate InputMethodEvent for ‘Fullwidth currency symbols’, as well. Thanks, Dmitry > On 17 Sep 2018, at 10:02, Prasanta Sadhukhan > wrote: > > Hi All, > > Please review a fix for an issue where > when "yen" symbol is entered from a keyboard using

Re: [12] Review request for JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut

ermission to check-in JDK 8u. > Thanks, > > Manajit > > > On 09/09/18 3:35 PM, Dmitry Markov wrote: >> Hi Manajit, >> >> The fix looks good to me. Can you port it to JDK 8u too, please? >> >> Thanks, >> Dmitry >> >>> On 7 Sep 2

Re: [12] Review request for JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut

to ensure >> that nothing is broken. >> >> Thanks, >> Dmitry >> >>> On 4 Sep 2018, at 18:54, Manajit Halder >> <mailto:manajit.hal...@oracle.com>> wrote: >>> >>> Hi Dmitry, >>> >>> Thanks for your reply.

Re: [12] Review request for JDK-8206392: [macosx] Cycling through windows (JFrames) does not work with keyboard shortcut

that nothing is broken. Thanks, Dmitry > On 4 Sep 2018, at 18:54, Manajit Halder wrote: > > Hi Dmitry, > > Thanks for your reply. Please see my reply inline. > > Thanks, > Manajit > > On 01/09/18 12:02 AM, Dmitry Markov wrote: >> Hi Manajit, >&

Re: [11] RFR 8205479: OS X: requestFocus() does not work properly for embedded frame

ritten for this issue? > > Regards, > Alexey > > On 06/08/2018 15:46, Dmitry Markov wrote: >> Thank you, Sergey! >> >> Looking for the second +1 from someone else. >> >> Thanks, >> Dmitry >> >>> On 5 Aug 2018, at 01:15, Sergey Bylokhov >

Re: [11] RFR 8205479: OS X: requestFocus() does not work properly for embedded frame

Thank you, Sergey! Looking for the second +1 from someone else. Thanks, Dmitry > On 5 Aug 2018, at 01:15, Sergey Bylokhov wrote: > > Looks fine. > > On 01/07/2018 02:26, Dmitry Markov wrote: >> Hi Sergey, >> The changes in CPlatformEmbeddedFrame are intended for

Re: [11] RFR 8130655: OS X: keyboard input in textfield is not possible if the window contained textfield is owned by EmbeddedFrame

let support - > although > I do recognise EmbeddedFrame is used in other scenarios too. > > But if this is just to enable a backport, then perhaps rushing it into 11 GA > is not needed. > > -phil. > > On 8/4/18, 5:13 PM, Sergey Bylokhov wrote: >> Looks fine. >>

Re: [11] RFR 8130655: OS X: keyboard input in textfield is not possible if the window contained textfield is owned by EmbeddedFrame

Thank you, Sergey! Looking for the second +1 from someone else. Thanks, Dmitry > On 5 Aug 2018, at 01:13, Sergey Bylokhov wrote: > > Looks fine. > > On 30/06/2018 08:12, Dmitry Markov wrote: >> Hi Sergey, >>> On 27 Jun 2018, at 01:15, Sergey Bylokhov >>

Re: [11] RFR 8205479: OS X: requestFocus() does not work properly for embedded frame

> On 1 Jul 2018, at 00:21, Sergey Bylokhov wrote: > > Hi, Dmitry > Can you please clarify why the changes in CPlatformEmbeddedFrame are > necessary? Why the same code does not exists in CViewPlatformEmbeddedFrame? > > On 27/06/2018 10:25, Dmitry Markov wrote: >>

Re: [11] RFR 8130655: OS X: keyboard input in textfield is not possible if the window contained textfield is owned by EmbeddedFrame

rame - Modified canBecomeKeyWindow() in AWTWindow to take into account window type and owner Could you review the new version, please? Thanks, Dmitry > > On 25/06/2018 03:35, Dmitry Markov wrote: >> Hello, >> Could you review a fix for jdk11, please? >> bug: https://b

Re: [11] RFR 8205479: OS X: requestFocus() does not work properly for embedded frame

ame which is used by SWT. > > On 25/06/2018 09:11, Dmitry Markov wrote: >> Hello, >> Could you review a fix for jdk11, please? >> bug: https://bugs.openjdk.java.net/browse/JDK-8205479 >> webrev: http://cr.openjdk.java.net/~dmarkov/8205479/webrev.00/ >> Problem

[11] RFR 8205479: OS X: requestFocus() does not work properly for embedded frame

Hello, Could you review a fix for jdk11, please? bug: https://bugs.openjdk.java.net/browse/JDK-8205479 webrev: http://cr.openjdk.java.net/~dmarkov/8205479/webrev.00/ Problem description: On Mac OSX when focus is transferred to some component located at embedded frame,

[11] RFR 8130655: OS X: keyboard input in textfield is not possible if the window contained textfield is owned by EmbeddedFrame

Hello, Could you review a fix for jdk11, please? bug: https://bugs.openjdk.java.net/browse/JDK-8130655 webrev: http://cr.openjdk.java.net/~dmarkov/8130655/webrev.00/ Problem description: On OS X platform a window does not receive keyboard input if it is owned by embedded frame. According to

[11] RFR 8200353: Shift or Capslock not working in Textfield after accentued keystrokes

Hello, Could you review a fix for jdk11, please? bug: https://bugs.openjdk.java.net/browse/JDK-8200353 webrev: http://cr.openjdk.java.net/~dmarkov/8200353/webrev.00/ The new mechanism of dead keys detection and processing was introduced by JDK-8139189 [1]. According to that changes dead key

  1   2   3   >