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

[Gregg Wonderly]

As a user of MACOS-X and Windows and Linux and as a developer, I'd really like 
to suggest that the issue with MACOS-X, is that the menu is an application 
thing, not a window thing.  The problem with Java on OS-X, is that Java Menus 
are "window things", not application things.  By promoting menus out of windows 
and onto the menu bar, the single window application has a convenient 
transformation into an OS-X application.   However, as soon as you introduce a 
modal window, such as a dialog, which would disable the main window access, and 
thus make the menu bar there, unusable, the OS-X menu bar extraction, from the 
main window, becomes problematic.

It seems to me, that what should actually happen, is that any "window" in java, 
that is "current", should have it's menu bar pushed in to the OS-X menubar.   If 
I have two or more, non-modal windows, and I click between them, I'd expect to 
have access to two or more distinct menu bars just like I would on other OSes 
using Java.  A modal window would just cause it's own menu bar to be used, and 
that would greatly simplify and unify the behavior to work as the application 
has been designed.

Gregg Wonderly

On 7/22/2013 9:02 AM, Sergey Bylokhov wrote:
> Hi, Leonid.
> Is seems to me that this is another issue, and both jdk6jdk8 behave incorrectly.
> When the window with mainmenubar is disposed, menu should be removed, because 
> it doesn't make sense in this case. So dispose of the window should be fixed.
> What do you think?
>
> On 22.07.2013 16:57, Leonid Romanov wrote:
>> 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, formally, we've got a regression. I'm not sure whether it is 
>> worth fixing, because it looks like a corner case, but still.
>>
>> On Jul 19, 2013, at 10:15 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> 
>> wrote:
>>
>>> Hello,
>>> Please review the fix for jdk 8 and 7u40.
>>> The fix for JDK-8010906 don't take into account situation then first parent 
>>> has no menu bar, but the second has.
>>> So it introduce the next scenario:
>>> #1. Open the window with File menu.
>>> #2. Open modal dialog1 =>File menu is disabled
>>> #3. Open modal dialog2 =>File menu disappears
>>> #4. Close dialog two
>>> #5. Close dialog one. File menu reappears, but File still disabled
>>>
>>> The steps #3. occurred, because CMenuBar.activate resets the current menubar 
>>> if a passed javaMenuBar is null.
>>> The steps #5. occurred, because at step #3 we do not remove our nsmenu from 
>>> the deleted NSMenuItem, when the appropriate NSMenuItem removed from 
>>> mainMenu. So at step #5 we got a situation, when our nsmenu was added to the 
>>> two different nsmenuitems: old(disabled) and new(enabled).
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017189
>>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8017189/webrev.00
>>>
>>> -- 
>>> Best regards, Sergey.
>>>
>
>