This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Start NB with -ui com.sun.java.swing.plaf.gtk.GTKLookAndFeel in 1.4.2 b19. (I also used -J-Dnetbeans.tab.close.button.enabled=false in case it matters.) Right-click on any tab, e.g. Runtime. An exception is thrown and there is no context menu.
Created attachment 9708 [details] Stack trace
Sorry, forgot - dev 030402.
Might occur in 3.5 too, pls. check.
Worse - *any* popup menu seems to throw a CCE.
Created attachment 9710 [details] Some more stack traces
I'd call this one a bug in their look and feel. There is no contract that getUI on a popup menu must return a class supplied by the look and feel in question - the method can be overridden by subclasses to return whatever UI they feel is appropriate. Lines 410-411 of SynthMenuItemUI: //PENDING: SynthPopupMenuUI popupUI = (SynthPopupMenuUI) ((JPopupMenu)parent).getUI(); The PENDING comment may mean they are aware of the problem. I patched the JDK, and we are returning an instance of org.openide.awt.NbPopupMenuUI. I'll see if I can find a way for us to live without it, but it might be a pretty big change at this late date. I'm digging around in CVS to try to figure out why this class was necessary (maybe some old Swing bugs?). All that it seems to do is subclass BasicPopupMenuUI and install the usual actions for arrow keys and invoking via space or enter - nothing that any normal popup menu UI doesn't also need, and nothing that couldn't be done by installing the keyboard actions into the popup menu from somewhere else, rather than from a UI class. Adding Peter Zavadsky to cc - he did the last edits to this file, maybe he can shed some light.
Filed JDK bug 4844816, priority 1, severity 2. I'll evaluate the possibilities of killing this UI class, but it may be too major a change for 3.5 - and it needs to be fixed in the JDK - any application supplying its own UI classes will run into the same problem.
Interesting - I removed all usage of NbPopupMenuUI from NetBeans. Result: No change. Keyboard navigation works perfectly, including issue 11048. Invocation is even perceptibly faster. Strange but true. Unfortunately, the original author of this class no longer works on NetBeans, so it may not be possible to find out what the original purpose of it was. As far as I can tell, whatever NbPopupMenuUI was created for, it's job is done, at least in >= JDK 1.4.1. I'll run some tests and see if we can really eliminate it, but it looks like it.
Removing this UI class does revert issue 11048 on JDK 1.3, but it works fine on 1.4. If the unit tests pass, I believe we can test if we are on >= 1.4.1 and if so, not use NbPopupMenuUI. If all goes well, we can also integrate it for 3.5.
Created attachment 9767 [details] Patch to only use NbPopupUI on < JDK 1.4.1
Created attachment 9768 [details] Binary patch of the above
I agree with the proposed patch. Custom NB UI classes should be deleted whenever possible. Anyway the ultimate problem is not JDK 1.3 either - it is JInlineMenu, and Actions.SubMenu's use of it. IMHO we should deprecate JInlineMenu for real (remove all uses in our code) and either: 1. Avoid creating actions whose presenter produces an indeterminate form. E.g. for Actions.SubMenu, *always* create a submenu. If it has one item, fine. If it has no items, add a disabled dummy menu item labelled "Empty". 2. Create a new API interface: public interface Presenter { // current interfaces, then... public interface VariableMenu { JMenuItem[] getMenuPresenters(); } public interface VariablePopup { JMenuItem[] getPopupPresenters(); } } understood by relevant UI classes, such as MenuBar, various util methods to create popups, etc. They would ask for a possibly empty list of menu items (or nulls for separators), and insert them all (in order) into the menu. Actions.SubMenu would be deprecated. Either of these approaches would solve a lot of nasty Swing problems that we have had.
Created attachment 9778 [details] Better patch, ignore previous
Created attachment 9779 [details] Better patch, binary version
the second patch verified
Patch committed to trunk. Raise priority if it should be merged into 3.5 and let me know.
I've committed the last patch to the trunk. It solves the problem for the propertysheet toolbar, but not for other toolbars. Attaching a logging binary patch which should allow you to find out what the main toolbars are trying to create when it fails for them.
Created attachment 9786 [details] Binary diagnostic patch
last patch is for diagnostic of issue 32673, not this one :)
Dafe please review the patch, we need a fix for 3.5. Tim, please wait for review and ask for integretion to release35 branch, thanks in advance.
I reviewed the code and I approve. Fix does exactly what was mentioned - use NbPopupMenuUI only for jdk version 1.3. Safe fix, once we tested that regular JPopupMenu is ok in JDK >=1.4 .
A comment from the JDK engineer regarding fix of #4844816: "I can fix the exception, but then the accelerators won't line up because you guys are using a custom PopupUI. Do you intend to not use a custom PopupUI for your final release?" Tim, could you please re-evaluate, based on that comment?
I did implement a workaround in the trunk (which we could port to 3.5), so we no longer use NbPopupMenuUI for popup menus on > 1.4 JDKs. And there is no GTK look and feel for < 1.4 JDKs, and 1.3 is the only place NbPopupUI does anything useful. I still feel that "workaround: none" status is valid, since it will break *any* application that uses its own UI classes. We're just lucky that we're in a release cycle and have a chance to fix it for the next release. The cast in their code needs to be qualified - it's a real bug of the kind you don't knowingly want to ship, ever - they have a method that returns PopupMenuUI and they blindly downcast it to their own implementation. That's wrong anywhere. If the accellerators don't line up, that's our problem and we can deal with it. If we port my workaround to 3.5, we won't have to do anything. Anyway, misaligned accellerators is better than ClassCastExceptions.
Ignore ToolbarPatch.jar, it belongs to another issue. Adding Petr Nejedly to cc for review - this issue is a candidate for 3.5.
The patch is OK (of course the one in trunk, not the one attached with System.out.println()s and with proper comments (even the trunk version talks about 1.4.1 while actually testing 1.4)
JDK bug #4844816 is to be fixed for the final release of 1.4.2. The remaining issue in NB core has been fixed in trunk, but is considered to be cosmetic only and too risky to fix in release35. Dropping prio from 1 to 3.
Okay. I couldn't find a release notes keyword, so I am cc'ing Patrick Keegan - this should be mentioned in the 3.5 release notes. Patrick, summary - NB 3.5 will not work using GTK look and feel in the JDK 1.4.2 beta, due to a bug in the GTK look and feel. This bug is scheduled to be fixed for JDK 1.4.2 release, so NetBeans + GTK look and feel should work fine there.
verified in [nb_dev](200306110100)