It's fixed in main trunk.

Oops, my mistake, reopening.

Editor guys, I'm leaving this issue for you, I don't know much about
editor's toolbar. Don't hesitate to ask if something is not clear.
Additionally, please check XP visual spec
http://ui.netbeans.org/docs/ui/ws/XP_style.html and modify toolbar
painting properly.  

Java module's NavigateAction creates a toolbar presenter with layout
BorderLayout(12,0) ... 
reassinging to java module.
For better imagination, please see image attached in the issue #48141
Especially, 1b and 6

Checking in NavigateAction.java;
/cvs/java/src/org/netbeans/modules/java/ui/actions/NavigateAction.java,v
 <--  NavigateAction.java
new revision: 1.16; previous revision: 1.15
done

Please, use setContentAreaFilled(false)
Your fix causes the minor problem with 
javax.swing.plaf.metal.MetalLookAndFeel & jdk1.5
See attached image.

Created attachment 17628 [details]
ugly toolbar drawing

Hmm, there is no setContentAreaFilled().
I used setOpaque(true) - Martine, can you test it? Thanks

Checking in NavigateAction.java;
/cvs/java/src/org/netbeans/modules/java/ui/actions/NavigateAction.java,v
 <--  NavigateAction.java
new revision: 1.17; previous revision: 1.16
done

Please note that JPanel's constructor calls setOpaque(true) already.
Generally, explicit calls to setOpaque should be regarded with
suspicion (and if necessary, may be signs of a Swing bug that should
be investigated); this method was never intended for general use,
according to Swing team developers.

Martine, does it help? Otherwise I do a rollback of my commit.

Unfortunatelly, problem is still visible...

OK - I did a rollback (of setOpaque()) . But I really don't know how
should I fix it.

I don't know to fix it also. (If it is even possible to fix it)

I would use setBorder(new EmptyBorder(0,2,0,0)) instead of 
setBorder(new EmptyBorder(0,2,0,8))  :-)

Yes, me too, but this issue was about editor toolbar, which is not
precisely according to the spec. This is the reason why the
EmptyBorder(0,2,0,8) was used :)

Yes, I know that :-)
It was just a small attempt to convince UI team to change UI spec :-)

CCing Tim, maybe he knows how to do that.

I did some ugliness for the combo boxes in the property sheet for Aqua, to always return 
Insets(0,0,0,0) from getInsets().  No idea if that's your problem here.  Maybe see if it either 
has a compound border with an outer EmptyBorder (which you can strip out), or if you can 
just give it a different (but decent looking border) - that's probably where the problem is.

Of course, if we intergrated the Navigator module we wouldn't need a combo box in the 
editor toolbar :-)

Ugly toolbar drawing fixed.
Checking in NavigateAction.java;
/cvs/java/src/org/netbeans/modules/java/ui/actions/NavigateAction.java,v
 <--  NavigateAction.java
new revision: 1.19; previous revision: 1.18
done

But the the toolbar is still not sized correctly. Some pixels missing,
but I don't think, that this issue is P3.
Feel free to change priority of this issue, but for me it is P5.

All visual appearance bugs should be P3 at least. Visual appearance gives the user a first 
impression about product's quality.

FYI, the toolbar also looks a bit funny on Aqua - no upper border, which looks a bit odd.

I'm sorry, I don't know how to fix it. I even don't know what is
wrong. It looks fine on my Windows XP. I give up.

Looks like we need some Swing experts here to help us with the issue.
Let me recap the problem:
We need a border for a swing component (JComboBox in a toolbar) and
that border must allow the gradient of the underlying toolbar to be
visible around the button. If we use EmptyBorder then the underlying
toolbar's gradient is not visible because of the border on Metal L&F.

As the setContentAreaFilled() is only present on the AbstractButton
(not JComponent) one idea that comes to my mind is to create a JPanel
with the combo and a disabled JButton on the right and call
setContentAreaFilled(false) on the JButton. The panel would be used as
the presenter. Unfortunately the JButton would have to have the
explicit preferred width (but preferred height should in fact be
delegated to the combo's preferred height) so either we would have to
override the JButton's getPreferredSize() or use setMinimumSize(new
Dimension(12, 0)) if that has effect (not sure).
 Of course this is a sort of hack so if anyone knows about any better
idea please speak up.

old issue, please re-evaluate

Navigation drop-down was replaced by Navigator module

Reorganization of java component