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.

Bug 32633 - Popup menu does not work in 1.4.2 GTK+ L&F - CCE
Summary: Popup menu does not work in 1.4.2 GTK+ L&F - CCE
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: _ tboudreau
Depends on: 35827
  Show dependency tree
Reported: 2003-04-04 15:28 UTC by Jesse Glick
Modified: 2008-12-22 16:40 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Stack trace (1.38 KB, text/plain)
2003-04-04 15:29 UTC, Jesse Glick
Some more stack traces (10.07 KB, text/plain)
2003-04-04 15:38 UTC, Jesse Glick
Patch to only use NbPopupUI on < JDK 1.4.1 (2.79 KB, patch)
2003-04-08 14:29 UTC, _ tboudreau
Details | Diff
Binary patch of the above (9.30 KB, application/octet-stream)
2003-04-08 14:31 UTC, _ tboudreau
Better patch, ignore previous (2.89 KB, patch)
2003-04-08 17:06 UTC, _ tboudreau
Details | Diff
Better patch, binary version (9.48 KB, application/octet-stream)
2003-04-08 17:07 UTC, _ tboudreau
Binary diagnostic patch (10.73 KB, application/octet-stream)
2003-04-08 18:29 UTC, _ tboudreau

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2003-04-04 15:28:51 UTC
Start NB with


in 1.4.2 b19. (I also used in
case it matters.)

Right-click on any tab, e.g. Runtime. An exception
is thrown and there is no context menu.
Comment 1 Jesse Glick 2003-04-04 15:29:22 UTC
Created attachment 9708 [details]
Stack trace
Comment 2 Jesse Glick 2003-04-04 15:31:36 UTC
Sorry, forgot - dev 030402.
Comment 3 Jesse Glick 2003-04-04 15:33:32 UTC
Might occur in 3.5 too, pls. check.
Comment 4 Jesse Glick 2003-04-04 15:37:51 UTC
Worse - *any* popup menu seems to throw a CCE.
Comment 5 Jesse Glick 2003-04-04 15:38:57 UTC
Created attachment 9710 [details]
Some more stack traces
Comment 6 _ tboudreau 2003-04-08 12:08:34 UTC
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:
SynthPopupMenuUI popupUI = (SynthPopupMenuUI)

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.
Comment 7 _ tboudreau 2003-04-08 12:40:03 UTC
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.
Comment 8 _ tboudreau 2003-04-08 13:26:38 UTC
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

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.
Comment 9 _ tboudreau 2003-04-08 14:07:23 UTC
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.
Comment 10 _ tboudreau 2003-04-08 14:29:59 UTC
Created attachment 9767 [details]
Patch to only use NbPopupUI on < JDK 1.4.1
Comment 11 _ tboudreau 2003-04-08 14:31:44 UTC
Created attachment 9768 [details]
Binary patch of the above
Comment 12 Jesse Glick 2003-04-08 15:46:33 UTC
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.
Comment 13 _ tboudreau 2003-04-08 17:06:32 UTC
Created attachment 9778 [details]
Better patch, ignore previous
Comment 14 _ tboudreau 2003-04-08 17:07:35 UTC
Created attachment 9779 [details]
Better patch, binary version
Comment 15 Marian Mirilovic 2003-04-08 17:31:52 UTC
the second patch verified
Comment 16 _ tboudreau 2003-04-08 18:16:33 UTC
Patch committed to trunk.  Raise priority if it should be merged 
into 3.5 and let me know.
Comment 17 _ tboudreau 2003-04-08 18:29:05 UTC
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.
Comment 18 _ tboudreau 2003-04-08 18:29:56 UTC
Created attachment 9786 [details]
Binary diagnostic patch
Comment 19 Marian Mirilovic 2003-04-08 18:37:51 UTC
last patch is for diagnostic of issue 32673, not this one :)
Comment 20 Marian Mirilovic 2003-04-10 10:18:20 UTC
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.
Comment 21 David Simonek 2003-04-10 15:20:58 UTC
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 .
Comment 22 Jan Chalupa 2003-04-10 20:09:56 UTC
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?
Comment 23 _ tboudreau 2003-04-10 20:28:23 UTC
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.
Comment 24 _ tboudreau 2003-04-14 11:51:40 UTC
Ignore ToolbarPatch.jar, it belongs to another issue.

Adding Petr Nejedly to cc for review - this issue is a candidate
for 3.5.
Comment 25 Petr Nejedly 2003-04-14 13:41:53 UTC
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)

Comment 26 Jan Chalupa 2003-04-16 10:01:20 UTC
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.
Comment 27 _ tboudreau 2003-04-16 10:13:34 UTC
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.
Comment 28 Marian Mirilovic 2003-06-11 10:39:40 UTC
verified in [nb_dev](200306110100)