JDK-7149062 : [macosx] dock menu don't show available frames
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2012-02-27
  • Updated: 2013-10-20
  • Resolved: 2012-06-09
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u6Fixed 8 b40Fixed
Related Reports
Relates :  
JDK-7174718 - [macosx] Regression in 7u6 b12: PopupFactory leaks DefaultFrames.
Description
Mac OS X 10.7.3 macmini4,1
Compile and run an application setting a dock icon menu (I've attached a simplest possible one). Using Apple Java 6, you will see that on top of menu there are all focusable frames listed. Well, some frames, anyway, and you can choose and focus one.
Not so in jdk7: nothing listed.
Comments
EVALUATION The fix: http://cr.openjdk.java.net/~anthony/8-26-windowListInDockMenu-7149062.2/
11-05-2012
EVALUATION As soon as I use the NSWindow class as a super class for AWT windows, they do appear in the dock icon menu. Given that the type of a window is set before creating a peer, we may have two implementations: one for NORMAL windows, and another, NSPanel-based, for UTILITY/undecorated windows.
17-04-2012
EVALUATION Mike Swingler <###@###.###>: I think the problem is that JDK7's top level windows are actually NSPanels, not NSWindows. This is so custom style bits can be applied to them (like titlebar-less, utility or HUD). Further work would need to be done to create an NSWindow subclass and an NSPanel subclass that could be dynamically changed at runtime to support "elevating" a window to a new style (and subsequently loosing it's name in the default Window menu - as it should) - but from Java's perspective, that should amount to a re-parenting operation. You can switch the superclass to NSWindow, but I think that will have unexpected consequences for untitled windows. If it doesn't, that only means you lose the extended styles like utility and HUD, which may be a reasonable tradeoff for getting the window title names in the Dock (but not in the main menu bar). Scott Kovatch <###@###.###>: >> All you need to do is have a menu named 'Window' in the nib file, and Cocoa will take care of updating it with all of the open windows, and adding it to the dock icon. The window has to have a title, I believe. That's how it used to work, anyway. >> >> >> >> Aren't we using the shared DefaultApp.nib? > > > > That isn't the problem (well, it's a problem, but not related to the Dock window menu). The default NIB has never had a Window menu because developers often add one themselves, and then there is two. We've lived without that from Java 1.3 to 1.6, and have only gotten a few bugs along the lines of "I can't create the dashes and diamonds in the real Window menu"...so people clearly want to be HIG compliant, but it hasn't seemed to occur to them that we should be doing it for them. I'd love to see a "use the platform Window menu" in the menu bar. Double-check DefaultApp.nib. There should be a free-floating NSMenu instance in there with a title of Window (or maybe a name of 'Window', I don't recall.) It's not added to the default menu bar. It's been there since 1.4.2 or so, unless someone took it out after I added it. :-) This isn't about adding a Window menu to the menu bar -- there's no way the AWT can handle that in an HIG-compliant way.
02-03-2012