Re: [9] Review Request: 7124250 [macosx] JOptionPane dialogs show wrong icons

itten, I’ve tested all > possible combinations of JDK/OSX version/Bundling/Webstart and all looks > correct, because we always use the icon from the Dock. > > With best regards. Petr. > > On Apr 23, 2014, at 7:46 PM, Leonid Romanov wrote: > >> Hello, >> I s

hg: jdk8/awt/jdk: 8027972: [macosx] Provide a regression test for JDK-8007006

Changeset: 4bc2414624e2 Author:leonidr Date: 2013-11-12 20:02 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/4bc2414624e2 8027972: [macosx] Provide a regression test for JDK-8007006 Reviewed-by: anthony + test/java/awt/MenuBar/8007006/bug8007006.java

[8] Review request for 8027972: [macosx] Provide a regression test for JDK-8007006

Hello, Please review a fix for 8027972: [macosx] Provide a regression test for JDK-8007006. Bug: https://bugs.openjdk.java.net/browse/JDK-8027972 webrev: http://cr.openjdk.java.net/~leonidr/8027972/webrev.00/ Thanks, Leonid.

hg: jdk8/awt/jdk: 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow

Changeset: 05f04b1c5bd0 Author:leonidr Date: 2013-10-30 20:54 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/05f04b1c5bd0 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow Reviewed-by: anthony, serb ! src/macosx/classes/sun/lwawt/macosx/

[8] Review request for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow

Hello, Please review a fix for 8013581: [macosx] Key Bindings break with awt GraphicsEnvironment setFullScreenWindow The problem here is that NSView's -enterFullScreenMode: withOptions: we currently use for entering exclusive full screen mode does it by creating a NSFullScreenWindow instance and

Re: RFR: 8025673: Disable X11 AWT toolkit

There was a discussion why we use HToolkit instead of HeadlessToolkit: http://mail.openjdk.java.net/pipermail/awt-dev/2012-July/003114.html So we might want to continue using it. Also, please be aware that there is HToolkit check in GraphicsToolkit.getHeadlessProperty() On Oct 22, 2013, at 1:23

hg: jdk8/awt/jdk: 8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS"

Changeset: d72ca6dac444 Author:leonidr Date: 2013-10-22 16:45 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/d72ca6dac444 8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/s

Re: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" (plan B)

t; -- > best regards, > Anthony > > On 10/16/2013 11:19 PM, Leonid Romanov wrote: >> >> On Oct 16, 2013, at 9:37 PM, Anthony Petrov >> wrote: >> >>> Hi Leonid, >>> >>> The problem with overriding NSApplication -sendEvent: is that y

Re: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" (plan B)

are really unusual: if we and all other responders in the chain return NO, then Cocoa will construct another NSEvent and call -performKeyEquivalent for that event. Returning YES from the -performKeyEquivalent prevents that. However, this means that Cocoa won't call -performKeyEquivalent for t

[8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS" (plan B)

Hello, This is plan B version of the fix for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS". The previous, proper version of the fix has been reviewed here: http://mail.openjdk.java.net/pipermail/awt-dev/2013-September/005441.html Unfortunately, I can't proceed with that v

Re: [8] Review Request: JDK-8024864 [macosx] Problems with rendering of controls

t; bounds from CPlatformWindow, > because it's not an only implementation of the PlatformWindow. So this fix is > the only option I see. > > With best regards. Petr. > > On 10.10.2013, at 15:27, Leonid Romanov wrote: > >> There is "nativeBounds" field in CPlatformW

Re: [8] Review Request: JDK-8024864 [macosx] Problems with rendering of controls

There is "nativeBounds" field in CPlatformWindow. Can't we use it instead of adding yet another bounds in LWWindowPeer? On 10.10.2013, at 11:56, Petr Pchelko wrote: > Hello, AWT Team. > > Please review the fix for the issue: > https://bugs.openjdk.java.net/browse/JDK-8024864 > The fix is avail

hg: jdk8/awt/jdk: 8016551: JMenuItem in WindowsLookAndFeel can't paint default icons

Changeset: fba62451d705 Author:leonidr Date: 2013-10-09 21:15 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/fba62451d705 8016551: JMenuItem in WindowsLookAndFeel can't paint default icons Reviewed-by: alexsch, serb ! src/share/classes/com/sun/java/swing/plaf/windows/Window

hg: jdk8/awt/jdk: 8019623: Lack of synchronization in AppContext.getAppContext()

Changeset: 976e5f580124 Author:leonidr Date: 2013-10-09 20:59 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/976e5f580124 8019623: Lack of synchronization in AppContext.getAppContext() Reviewed-by: anthony, art ! src/share/classes/sun/awt/AppContext.java + test/sun/awt/AppC

Re: [8] Review request for 8019623: Lack of synchronization in AppContext.getAppContext()

Ok, here an updated webrev then, with the test added: http://cr.openjdk.java.net/~leonidr/8019623/webrev.01/ On Oct 8, 2013, at 7:43 PM, Artem Ananiev wrote: > > On 10/8/2013 6:54 PM, Leonid Romanov wrote: >> Hi, >> I tried different variations of your suggestion and none o

hg: jdk8/awt/jdk: 8004050: [macosx] The 'ESC' key does not work with jdk8

Changeset: e591ac19174f Author:leonidr Date: 2013-10-09 01:03 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e591ac19174f 8004050: [macosx] The 'ESC' key does not work with jdk8 Reviewed-by: alexsch, serb ! src/macosx/classes/com/apple/laf/AquaComboBoxUI.java ! src/macosx/c

Re: [8] Review request for 8019623: Lack of synchronization in AppContext.getAppContext()

Thanks, > > Artem > > On 10/2/2013 6:22 PM, Leonid Romanov wrote: >> Hello, >> Please, review a fix for 8019623: Lack of synchronization in >> AppContext.getAppContext(). I don't think it makes sense to ensure that >> AppContext.getAppContext()/SunTo

Re: [8] Review request for 8019623: Lack of synchronization in AppContext.getAppContext()

n check > that all the returned AC's are equal. Although it won't 100% fail before your > fix, it should 100% pass after it. What do you think about it? > > Thanks, > > Artem > > On 10/2/2013 6:22 PM, Leonid Romanov wrote: >> Hello,

Re: [8] Review request for 8013553: [macosx] java.awt.FileDialog removes file extensions

Looks good to me. On 03.10.2013, at 13:07, Oleg Pekhovskiy wrote: > Hi all, > > please review the fix > http://cr.openjdk.java.net/~bagiras/8013553.1/ > for > https://bugs.openjdk.java.net/browse/JDK-8013553 > > setExtensionHidden(NO) method of NSSavePanel doesn't work as expected and > that'

[8] Review request for 8019623: Lack of synchronization in AppContext.getAppContext()

Hello, Please, review a fix for 8019623: Lack of synchronization in AppContext.getAppContext(). I don't think it makes sense to ensure that AppContext.getAppContext()/SunToolkit.createNewAppContext() is thread safe, because in practice we haven't had any problems with this combination. What we

hg: jdk8/awt/jdk: 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown.

Changeset: 244f2ee51f31 Author:leonidr Date: 2013-10-02 17:06 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/244f2ee51f31 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. Reviewed-by: anthony, serb ! s

Re: [8] Review Request: JDK-8024158 [macosx] java/awt/EventDispatchThread/LoopRobustness/LoopRobustness still failed after fix JDK-8022247; since jdk8b96

Looks good, assuming that the rest of the requestWindowFocus() code doesn't call anything that eventually calls getAppContext(). On 10/2/2013 16:17, Petr Pchelko wrote: Hello, AWT Team. Please review the fix for the issue: https://bugs.openjdk.java.net/browse/JDK-8024158 The fix is available a

Re: [8] Review request for 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown.

avoid any confusion in the future. We still have the time to fix any regressions, in case they arise. Here is an updated webrev: http://cr.openjdk.java.net/~leonidr/8023994/webrev.01/ On Sep 27, 2013, at 9:33 PM, Leonid Romanov wrote: > Yes, this code looked suspicious for me as well, I su

Re: [8] Review request for 7033533: realSync() doesn't work with Xfce

at to sniff? Perhaps we would have to file bugs in too many bug tracking systems. "ICCCM establishes conventions, which are basically suggestions." Thanks, -yan On 10/01/2013 04:38 PM, Leonid Romanov wrote: I agree with you, but it would change our approach to the fix: for instance, we mi

Re: [8] Review request for 7033533: realSync() doesn't work with Xfce

d. Thanks, -yan On 10/01/2013 04:01 PM, Leonid Romanov wrote: By the way, I was reading Inter-Client Communication Conventions Manual so I could better understand the fix, and found the following: "4.3. Communication with the Window Manager by Means of Selections For each screen they

Re: [8] Review request for 7033533: realSync() doesn't work with Xfce

vice event (SelectionRequest), that should be excluded from the number of dispatched native events. IMHO, the previous number "2" should have been commented, but, that did not happen. Thanks, Oleg On 25.09.2013 18:11, Leonid Romanov wrote: Hi, I'm not an expert in X11 programming,

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

I'm not sure whether I'm allowed to review the backport of my own fix, but anyway, it looks good. On 10/1/2013 9:39, dmitry markov wrote: 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:/

Re: [8] Review request for 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown.

On Sep 27, 2013, at 9:25 PM, Sergey Bylokhov wrote: > Hi, Leonid. > In this case the code in the XBaseMenuWindow.doDispose() call > XToolkit.targetDisposedPeer(target, this); for the wrong target? Or probably > this target is alwase null? > > On 27.09.2013 20:32, Leonid Romano

[8] Review request for 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown.

Hello, Please review a fix for 8023994: Right click on the icon added to the system tray for the first time, java.lang.IllegalArgumentException thrown. The problem here is that for popup menus the "target" field of XBaseMenuWindow class is not a MenuComponent corresponding to the popup, but a co

Re: [8] Review request for 7033533: realSync() doesn't work with Xfce

Hi, I'm not an expert in X11 programming, so I can't comment about the fix in general, but I think the line 2436, "return getEventNumber() - event_number > 3", really asks for a comment. On 9/25/2013 16:38, Oleg Pekhovskiy wrote: Hi all, please review the fix http://cr.openjdk.java.net/~bagi

hg: jdk8/awt/jdk: 8022555: [macosx] AppleScriptEngine.jar MUST call java.awt.Toolkit.getDefaultToolkit() lazily

Changeset: 2ed1584d62c5 Author:leonidr Date: 2013-09-24 18:24 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2ed1584d62c5 8022555: [macosx] AppleScriptEngine.jar MUST call java.awt.Toolkit.getDefaultToolkit() lazily Reviewed-by: anthony, serb ! src/macosx/classes/apple/app

Re: [8] Review request for 8022555: [macosx] AppleScriptEngine.jar MUST call java.awt.Toolkit.getDefaultToolkit() lazily

hy we need toolkit there? On 19.09.2013 16:35, Leonid Romanov wrote: Hello, This is a RFE from the Nashorn team to change AppleScriptEngine initialization from static to lazy, when app actually asks for an AppleScriptEngine instance. They've requested it because AppleScriptEngine initiali

[8] Review request for 8004050: [macosx] The 'ESC' key does not work with jdk8

Hello, Please, review a fix for 8004050: [macosx] The 'ESC' key does not work with jdk8 Bug: https://bugs.openjdk.java.net/browse/JDK-8004050 Webrev: http://cr.openjdk.java.net/~leonidr/8004050/webrev.00/ Thanks, Leonid.

hg: jdk8/awt/jdk: 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol

Changeset: 602e5d0141d3 Author:leonidr Date: 2013-09-19 23:46 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/602e5d0141d3 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol Reviewed-by: anthony, serb ! makefiles/GensrcProperties.gmk + src/ma

hg: jdk8/awt/jdk: 7144065: [macosx] Orphaned Choice popup window

Changeset: e292d504ad68 Author:leonidr Date: 2013-09-19 22:33 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e292d504ad68 7144065: [macosx] Orphaned Choice popup window Reviewed-by: anthony, serb Contributed-by: alexander.potoch...@oracle.com ! src/macosx/classes/sun/lwawt/

[8] Review request for 8022555: [macosx] AppleScriptEngine.jar MUST call java.awt.Toolkit.getDefaultToolkit() lazily

Hello, This is a RFE from the Nashorn team to change AppleScriptEngine initialization from static to lazy, when app actually asks for an AppleScriptEngine instance. They've requested it because AppleScriptEngine initialization triggers LWCToolkit initialization, which currently happens as a res

Re: [8] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol

gt;> -- >> best regards, >> Anthony >> >> On 09/13/2013 05:10 PM, Leonid Romanov wrote: >>> The main bug simply states that "accelerators are displayed as Meta instead >>> of the Command symbol", but if you look at duplicates they are mostly

[8] Review request for 7144065: [macosx] Orphaned Choice popup window

Hello, This is a forward port of AlexP fix for JDK 7u4. Somehow, it haven't made in JDK 8, so we still have the problem described in the bug report. bug: https://bugs.openjdk.java.net/browse/JDK-7144065 webrev: http://cr.openjdk.java.net/~leonidr/7144065/webrev.00/ Thanks, Leonid.

hg: jdk8/awt/jdk: 7188071: closed/java/awt/TrayIcon/TrayIconSecurity/GrantedTrayIconTest fails

Changeset: 2c240454c192 Author:leonidr Date: 2013-09-18 18:36 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/2c240454c192 7188071: closed/java/awt/TrayIcon/TrayIconSecurity/GrantedTrayIconTest fails Reviewed-by: anthony, serb ! src/solaris/classes/sun/awt/X11/XTrayIconPeer.

[8] Review request for 7188071: closed/java/awt/TrayIcon/TrayIconSecurity/GrantedTrayIconTest fails

Hello, Please review a fix for 7188071: closed/java/awt/TrayIcon/TrayIconSecurity/GrantedTrayIconTest fails. This is a rather old issue, dating back to jdk8-b48. The test uses custom security policy which grants "accessSystemTray" permission, but lacks "accessEventQueue" permission. I see no re

Re: [8] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol

> -- > best regards, > Anthony > > On 09/13/2013 04:06 PM, Leonid Romanov wrote: >> I've implemented the approach you suggested, but it didn't pass the >> regression test I've written for this bug. Even though the test isn't run in >> headless mod

Re: [8] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol

AWTAccessor? This would help avoid > checking for a specific platform in our shared code. > > -- > best regards, > Anthony > > On 09/12/13 15:30, Leonid Romanov wrote: >> Yes, I'll use OSInfo instead. As for property file name, could you >> suggest a better

Re: [8] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol

Yes, I'll use OSInfo instead. As for property file name, could you suggest a better one? On 12.09.2013, at 15:26, Sergey Bylokhov wrote: > Hi, Leonid. > i think that you can try to reuse OSInfo class. > Also I doubt about property file name. > > On 12.09.2013 9:09, Leonid

Re: [8] Request for review: 7124537 [macosx] Menu shortcuts for all menu items should be disabled if a menu itself is disabled

LWCtoolkit diff is empty. Is it because you've only changed white spaces? On 9/11/2013 19:39, Sergey Bylokhov wrote: Hello, Please review direct forward port from jdk7u to jdk 8. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7124537 Webrev can be found at: http://cr.openjdk.java.net/

Re: [8] Request for review: 7124537 [macosx] Menu shortcuts for all menu items should be disabled if a menu itself is disabled

Looks good then. On 9/11/2013 21:15, Sergey Bylokhov wrote: On 11.09.2013 21:14, Leonid Romanov wrote: LWCtoolkit diff is empty. Is it because you've only changed white spaces? Yes: http://cr.openjdk.java.net/~serb/7124537/webrev.00/src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java.

Re: [8] Review request for 8007219 [macosx] Frame size reverts meaning of maximized attribute if frame size close to display

Hi, Looks good to me. On 9/11/2013 15:17, Alexander Scherbatiy wrote: Hello, Could you review the fix: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007219 webrev: http://cr.openjdk.java.net/~alexsch/8007219/webrev.00 The fix check if an NSWindow is in zoomed state before max

[8] Review request for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol

Hello, Please review a fix for 7129133: [macosx] Accelerators are displayed as Meta instead of the Command symbol. bug: http://bugs.sun.com/view_bug.do?bug_id=7129133 webrev: http://cr.openjdk.java.net/~leonidr/7129133/webrev.00/ Thanks, Leonid.

hg: jdk8/awt/jdk: 8003901: [macosx] Need test for JDK-8002114

Changeset: 0cc00c11e17e Author:leonidr Date: 2013-09-10 20:42 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/0cc00c11e17e 8003901: [macosx] Need test for JDK-8002114 Reviewed-by: anthony, serb ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwice

Re: [8] Review request for JDK-8020209: [macosx] Mac OS X key event confusion for "COMMAND PLUS"

er (e.g., in case OS X stops supporting the SPI, or we > break our own code ourselves). > > -- > best regards, > Anthony > > On 09/09/2013 03:20 PM, Leonid Romanov wrote: >> Hello, >> This is a bug with a long history. It all started with 1* followed by 2*. >>

[8] Review request for JDK-8003901: [macosx] Need test for JDK-8002114

Hello, Please review a fix for JDK-8003901: [macosx] Need test for JDK-8002114. The fix adds another key stroke to the existing ActionListenerCalledTwice test. Bug: http://bugs.sun.com/view_bug.do?bug_id=8003901 Webrev: http://cr.openjdk.java.net/~leonidr/8003901/webrev.00/ Thanks, Leonid.

Re: [8] Review request for 8007156 [macosx] Wrong events in processKeyBinding of JTable

Looks good. On Aug 20, 2013, at 6:12 PM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007156 > webrev: http://cr.openjdk.java.net/~alexsch/8007156/webrev.00 > > The fix sets extended key code for the key e

hg: jdk8/awt/jdk: 8022997: [macosx] Remaining duplicated key events

Changeset: 3930a827160a Author:leonidr Date: 2013-08-15 01:17 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/3930a827160a 8022997: [macosx] Remaining duplicated key events Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/CMenuItem.m ! test/javax/swing/JMenuItem/Actio

[8] Review request for 8022997: [macosx] Remaining duplicated key events

Hello, Please review a one line fix for 8022997: [macosx] Remaining duplicated key events. NsCharToJavaChar() we call at CMenuItem.m:92 translates NSCarriageReturnCharacter (which is the key code generated by OS X when user presses "enter" key) into NSNewlineCharacter. So, in order to filter out

Re: [8] Request for review: 7124339 [macosx] setIconImage is not endlessly tolerant to the broken image-arguments

Looks good. On 8/6/2013 17:15, Sergey Bylokhov wrote: Hello, Please review the fix for jdk 8. After the fix of 6436455 we skip window's incorrect icon on all platforms. In this fix we do the same for OSX. See additional info in the bug description Input validation was removed, because it is do

hg: jdk8/awt/jdk: 8022247: java/awt/EventDispatchThread/LoopRobustness/LoopRobustness throws NPE

Changeset: 07abddc1d7f2 Author:leonidr Date: 2013-08-06 17:07 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/07abddc1d7f2 8022247: java/awt/EventDispatchThread/LoopRobustness/LoopRobustness throws NPE Reviewed-by: art ! test/java/awt/EventDispatchThread/LoopRobustness/LoopR

[7u] Review request for 8021381: JavaFX scene included in Swing JDialog not starting from Web Start

Hello, Please review a fix for 8021381. bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8021381 webrev: http://cr.openjdk.java.net/~leonidr/8021381/webrev.00/ Thanks, Leonid.

[8] Review request for 8022247: java/awt/EventDispatchThread/LoopRobustness/LoopRobustness throws NPE

Hello, Please review a fix for 8022247: java/awt/EventDispatchThread/LoopRobustness/LoopRobustness throws NPE . The problem is in the test: the rules regarding AppContext usage have changed since 7u25, so, because the test creates its own thread group and an AppContext for it, it also must crea

hg: jdk8/awt/jdk: 8021381: JavaFX scene included in Swing JDialog not starting from Web Start

Changeset: e76b1568d002 Author:leonidr Date: 2013-08-02 15:42 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/e76b1568d002 8021381: JavaFX scene included in Swing JDialog not starting from Web Start Reviewed-by: art, dcherepanov ! src/share/classes/sun/awt/AppContext.java

hg: jdk8/awt/jdk: 8021815: Add regression test for JDK-8007267

Changeset: 645a37a3559f Author:leonidr Date: 2013-08-01 01:26 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/645a37a3559f 8021815: Add regression test for JDK-8007267 Reviewed-by: serb + test/com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java

Re: [8] Request for review: JDK-8013611 Modal dialog fails to obtain keyboard focus

Looks good. On Jul 3, 2013, at 3:52 PM, Anton V. Tarasov wrote: > Please, review a fix. > > jira: https://jbs.oracle.com/bugs/browse/JDK-8013611 > webrev: http://cr.openjdk.java.net/~ant/JDK-8013611/webrev.0 > > The fix refines a condition by which a focus request is directed through the > b

Re: [8] Review request for 8021815: Add regression test for JDK-8007267

Here is a second version of the fix: http://cr.openjdk.java.net/~leonidr/8021815/webrev.01/ On Jul 29, 2013, at 9:21 PM, Sergey Bylokhov wrote: > > On 29.07.2013 21:10, Leonid Romanov wrote: >> I see, thanks… Could you point me to some test that does it in a right way, >>

Re: [8] Review request for 8021815: Add regression test for JDK-8007267

u need to use a reflection. > > On 29.07.2013 21:03, Leonid Romanov wrote: >> Hello, >> Please review a fix 8021815: Add regression test for JDK-8007267. This fix >> simply adds a regression test for 8007267: [macosx] >> com.apple.eawt.Application.setDefaul

[8] Review request for 8021815: Add regression test for JDK-8007267

Hello, Please review a fix 8021815: Add regression test for JDK-8007267. This fix simply adds a regression test for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working . Bug: http://bugs.sun.com/view_bug.do?bug_id=8021815 (might not be available yet) Webrev: http://cr.o

hg: jdk8/awt/jdk: 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working

Changeset: 7bd6eda2d217 Author:leonidr Date: 2013-07-26 16:22 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/7bd6eda2d217 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working Reviewed-by: anthony, serb ! src/macosx/classes/com/apple/eawt/_AppMenuBar

Re: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working

Yes, they won't. Same thing for Apple JDK 6. On Jul 26, 2013, at 3:53 PM, Sergey Bylokhov wrote: > Hi, Leonid. > As far I understand,shortcuts will not work, if the window without menubar > will be active, and defaultMenuBar will be added? > > On 26.07.2013 15:45,

Re: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working

st to add a comment here stating that the problem >> is known. >> >> The fix looks fine otherwise. Please consider it approved. >> >> -- >> best regards, >> Anthony >> >> On 07/26/2013 04:54 AM, Leonid Romanov wrote: >>> Hi, >>

Re: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working

uggest to add a comment here stating that the problem >> is known. >> >> The fix looks fine otherwise. Please consider it approved. >> >> -- >> best regards, >> Anthony >> >> On 07/26/2013 04:54 AM, Leonid Romanov wrote: >>> Hi

Re: [8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working

un loop iteration, or may be the interval between windowDidBecomeKey/windowDiidResignKey is too short. > -- > best regards, > Anthony > > On 07/26/2013 04:54 AM, Leonid Romanov wrote: >> Hi, >> Please review a fix for 8007267: [macosx] >> com.apple.eawt.Appli

[8] Review request for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working

Hi, Please review a fix for 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working. It doesn't work because a bunch of code required to make it work is commented out. So, I've uncommented it, but since it isn't enough, I've also done a number of additional minor modificat

Re: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac

is > disposed, it dispose all its child windows. > > On 24.07.2013 15:46, Leonid Romanov wrote: >> Looks good for me as well. The only thing that is not clear to me is the >> memory management in AWTWindow: since every child references its parent now, >> wouldn't

Re: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac

09:37 PM, Sergey Bylokhov wrote: >>> Hello. >>> Please review updated version of the fix: >>> http://cr.openjdk.java.net/~serb/8017189/webrev.01 >>> After the fix, for dialogs we activates a menubar from the first visible >>> and enabled owner. I use awtwindow

Re: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac

On 7/23/2013 14:06, Sergey Bylokhov wrote: On 22.07.2013 23:32, Leonid Romanov wrote: Well, I'd like us to stay consistent with JDK 6. However, if we decide to fix this issue in some other way, we need to be consistent with other possible cases, like setting frame's menu to n

Re: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac

dialog2) doesn't formally have a menu (opposite->javaMenuBar is NULL). This means that dialog1 now has a menu that is formally inactive. Since I don't really understand the purpose of -(void) deactivate method, I can't say whether the situation I've described above is prob

Re: [8] Request for review: 8017189 [macosx] AWT program menu disabled on Mac

Hi. Here is a test case that, with your patch applied, works differently than JDK 6: 1. Show JFrame with a menu 2. Create a modal dialog with the frame as a parent 3. Dispose the frame 4. Make dialog visible With JDK 6, the dialog's menu will be disabled. With JDK 8, it will be enabled. So, for

hg: jdk8/awt/jdk: 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread

Changeset: c566daef4877 Author:leonidr Date: 2013-07-11 18:23 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/c566daef4877 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread Reviewed-by: art, anthony ! src/macosx/clas

Re: [8] Review request for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread

On Jul 9, 2013, at 6:38 PM, Artem Ananiev wrote: > > On 7/8/2013 8:35 PM, Leonid Romanov wrote: >> I encountered the case of unset handlerContext while testing SwingSet3 Web >> Start app. It is triggered by selecting SwingSet3->About from the global >> menu bar.

hg: jdk8/awt/jdk: 8019265: [macosx] apple.laf.useScreenMenuBar regression comparing with jdk6

Changeset: b7cbad879d63 Author:leonidr Date: 2013-07-08 19:47 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/b7cbad879d63 8019265: [macosx] apple.laf.useScreenMenuBar regression comparing with jdk6 Reviewed-by: anthony ! src/macosx/native/sun/awt/CMenuItem.m ! test/javax/s

Re: [8] Review request for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread

3, at 8:14 PM, Artem Ananiev wrote: > > The changes look fine, except _AppEventDispatcher.dispatch(). Should we > dispatch the event at all, in case handlerContext hasn't been set (or set to > null, which should never happen)? I would say no. > /*= > Thanks, >

[8] Review request for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread

Hello, Please review a fix for 8020038: [macosx] Incorrect usage of invokeLater() and likes in callbacks called via JNI from AppKit thread, As you aware, recent AppContext usage change in 7u25 exposed a number of AppContext related issues in our code. This particular bug focuses on the incorrect

Re: [8] Review request for 8019265: [macosx] apple.laf.useScreenMenuBar regression comparing with jdk6

e way. > > Thank you, > Denis. > > On Jul 5, 2013, at 11:18 PM, Leonid Romanov wrote: > >> Yes, it does pass with the fix. >> >> On 7/5/2013 16:20, Sergey Bylokhov wrote: >>> Hi, Leonid. >>> The test from the bug description (JTextArea +

Re: Review request (extra small) for 8012925 Missing return value in jdk/src/macosx/native/sun/awt/AWTEvent.m

Looks OK. On 7/6/2013 1:36, Tim Bell wrote: Hello everyone Unfortunately there is no public link for 8012925 This is a one-line change in jdk/src/macosx/native/sun/awt/AWTEvent.m to return a value (0) instead of returning nothing. Returning 0 is consistent with the code at line 418 in the s

Re: [8] Review request for 8019265: [macosx] apple.laf.useScreenMenuBar regression comparing with jdk6

Yes, it does pass with the fix. On 7/5/2013 16:20, Sergey Bylokhov wrote: Hi, Leonid. The test from the bug description (JTextArea + shortcut) is passed after the fix? On 05.07.2013 3:47, Leonid Romanov wrote: Hello, Please review a fix for 8019265: [macosx] apple.laf.useScreenMenuBar

Re: [7u40] Review request for 8019628: [macosx] closed/java/awt/Modal/BlockedMouseInputTest/BlockedMouseInputTest.html failed since 7u40b30 on MacOS

Hi, Looks good. On 7/5/2013 17:47, Alexander Scherbatiy wrote: Hello, Could you review the fix for the regression in JDK 7u40: bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8019628 webrev: http://cr.openjdk.java.net/~alexsch/8019628/webrev.00 Generated enter/exit mouse events have b

[8] Review request for 8019265: [macosx] apple.laf.useScreenMenuBar regression comparing with jdk6

Hello, Please review a fix for 8019265: [macosx] apple.laf.useScreenMenuBar regression comparing with jdk6 . The problem here is that NsCharToJavaChar() function we use for translating keystrokes returns CHAR_UNDEFINED for keys like arrows, which is undesirable in case of CMenuItem. bug: http:/

hg: jdk8/awt/jdk: 8014264: The applet pathguy_TimeDead throws java.lang.NullPointerException in java console once click drop-down check box.

Changeset: 1c607ebfc180 Author:leonidr Date: 2013-06-20 18:50 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/1c607ebfc180 8014264: The applet pathguy_TimeDead throws java.lang.NullPointerException in java console once click drop-down check box. Reviewed-by: art, anthony, se

Re: [8] Request for review: JDK-8016555: Regression: Focus issues with Oracle WebCenter Capture applet

Thanks! On 6/19/2013 16:17, Anthony Petrov wrote: The fix looks fine to me, too. -- best regards, Anthony On 06/14/2013 04:41 PM, Anton V. Tarasov wrote: Thank you for the review. On 14.06.2013 16:17, Leonid Romanov wrote: Looks good then. On 6/14/2013 16:10, Anton V. Tarasov wrote: It&#

Re: [8] Request for review: JDK-8016555: Regression: Focus issues with Oracle WebCenter Capture applet

Looks good then. On 6/14/2013 16:10, Anton V. Tarasov wrote: It's Ok because the check actually should be correct for any type of toplevels. Thanks, Anton. On 14.06.2013 10:54, Leonid Romanov wrote: Hi, The check you've added also affects lightweight frames (because of line 382)

Re: [8] Request for review: JDK-8016555: Regression: Focus issues with Oracle WebCenter Capture applet

Hi, The check you've added also affects lightweight frames (because of line 382). Is it OK? On 6/13/2013 6:52 PM, Anton V. Tarasov wrote: Hello, Please, review the fix. jira: https://jbs.oracle.com/bugs/browse/JDK-8016555 webrev: http://cr.openjdk.java.net/~ant/JDK-8014821/webrev.0 It's rep

Re: [8] Review request for 8014264: The applet pathguy_TimeDead throws java.lang.NullPointerException in java console once click drop-down check box.

13 5:53 PM, Sergey Bylokhov wrote: Hi, Leonid. Does it mean that we cannot use InvokeAndW/Later on the toolkit thread? On 11.06.2013 12:48, Leonid Romanov wrote: Hi, Please review a fix for 8014264: The applet pathguy_TimeDead throws java.lang.NullPointerException in java console once click drop-d

[8] Review request for 8014264: The applet pathguy_TimeDead throws java.lang.NullPointerException in java console once click drop-down check box.

Hi, Please review a fix for 8014264: The applet pathguy_TimeDead throws java.lang.NullPointerException in java console once click drop-down check box. The problem here is that for applets prePostEvent is called within ThreadGroup that, by design, has no AppContext associated with it. So, when

Re: [8] Request for review: JDK-8013773: requestFocusInWindow to a disabled component prevents window of getting focused

It's hard to understand all the possible consequences, but otherwise the fix looks good. On 5/29/2013 10:32 AM, Anton V. Tarasov wrote: A friendly reminder (please, anyone). On 20.05.2013 17:34, Anton V. Tarasov wrote: Hello, Please, review the fix: jira: https://jbs.oracle.com/bugs/browse/

Fwd: Review request for 8014724: Broken 7u-dev build

Hi guys, Could any of you review the fix for the broken build, please? It's a trivial, one line fix. I just need the formal reviewer. Thanks, Leonid. Begin forwarded message: > From: Leonid Romanov > Subject: Review request for 8014724: Broken 7u-dev build > Date: May 16, 2013

hg: jdk8/awt/jdk: 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar

Changeset: 578fb8766200 Author:leonidr Date: 2013-04-22 19:24 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/578fb8766200 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/AWTEvent.h ! src/

Re: [8] Review request for 8010721: [macosx] In JDK7 the menu bar disappears when a Dialog is shown

Hi, For 1, perhaps you could use AWTWindow's javaPlatformWindow to get to corresponding LWWindowPeer, which has peerType field. On Mar 27, 2013, at 5:45 PM, Vladislav Karnaukhov wrote: > Hello, > > please review a fix for 8010721. > > bug: http://bugs.sun.com/view_bug.do?bug_id=8010721 > web

Re: [8] Review request for 8010721: [macosx] In JDK7 the menu bar disappears when a Dialog is shown

Also, for OS X bugs, please add "macosx-port-...@openjdk.java.net" to the CC On Mar 27, 2013, at 5:45 PM, Vladislav Karnaukhov wrote: > Hello, > > please review a fix for 8010721. > > bug: http://bugs.sun.com/view_bug.do?bug_id=8010721 > webrev: http://cr.openjdk.java.net/~vkarnauk/8010721/jd

Re: [7uX] Review request for 8010721: In JDK7 the menu bar disappears when a Dialog is shown

Yep, it's the fix for 7124310 and it hasn't been pushed into JDK 7 yet. However, I'll push it soon, so you can use it in your fix. On Mar 25, 2013, at 11:53 PM, Vladislav Karnaukhov wrote: > On 3/25/2013 03:51 PM, Leonid Romanov wrote: >> Hi, >> Is this the cod

Re: [7uX] Review request for 8010721: In JDK7 the menu bar disappears when a Dialog is shown

Hi, Is this the code that is present in JDK 8 but is absent in JDK 7? http://hg.openjdk.java.net/jdk8/awt/jdk/diff/094c963dca1b/src/macosx/native/sun/awt/AWTWindow.m On 3/25/2013 6:01 PM, Vladislav Karnaukhov wrote: Hello, please review an initial version of the fix for 8010721. This solut

[8] Review request for 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar

Hi, Please review a fix for 8008366: [macosx] ActionListener called twice for JMenuItem using ScreenMenuBar. The problem manifests itself when VK_DELETE is used as a menu accelerator. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008366 Webrev: http://cr.openjdk.java.net/~leonidr/800

hg: jdk8/awt/jdk: 8007006: [macosx] Closing subwindow loses main window menus

Changeset: fd61fcc1a5a9 Author:leonidr Date: 2013-01-31 18:25 +0400 URL: http://hg.openjdk.java.net/jdk8/awt/jdk/rev/fd61fcc1a5a9 8007006: [macosx] Closing subwindow loses main window menus Reviewed-by: anthony ! src/macosx/native/sun/awt/AWTWindow.m

Re: [8] Review request for 8007006 : [macosx] Closing subwindow loses main window menus

ound for some other problem with this fix. > > -- > best regards, > Anthony > > On 1/29/2013 19:57, Leonid Romanov wrote: >> Hi, >> Please review a fix for 8007006 : [macosx] Closing subwindow loses main >> window menus. The problem manifests itself when the g

  1   2   >