Bug 35083

Created attachment 11078 [details]
combo overreaching window

IMHO, when I tried to follow Lukas's workaround
it is impossible to select other value from drop-down list by clicking
on it by mouse.
the only wrkrnd for me is tu choose it by keyboard...

It's hard to change properties and  thus I thing is more serrious then P3.
Changing priority to P2

P3->P2

Very strange.  I do use a popup subclass, but they only
thing it does is override a method to improve the sizing
logic in the case the popup is too big - it should have
no effect on the value whatsoever.  I'm wondering if this
will turn out to be a Swing bug.

I cannot reproduce this on Windows XP at all.  Can you give
some more details on how to reproduce?  I tried the Executor
property of some Java classes, as well as others.  They all
worked correctly.

I tryed new dev build from 07/28 and it works.

Closing as works for me. 

But it definetly didn't work in 07/23 build and we tryed it at least
on two platforms - w2k, RH

Dan, could please check it on Linux ? and then reopen/verify, thanks.

OK Lukasi,

I've take todays NBdev build #2003-07-28-0100 and tested on my RH9,
using jdk1.4.2-b28 and I must to reopne it.

I could comfirm that value is set to the value you choose,
but it is still hard to select one of the drop-down-list is wider or
longer then are borders of properties window...

See the 2 others snapshots. The list is blinking while you move over
it with mouse cursor.
The only way how to choose a value is use the keyboard...

Created attachment 11172 [details]
list is wider then the properties window and thus it is blinking when mouse is over it

Created attachment 11173 [details]
list is longer then the properties window (just before attemt to select something from the list by mouse)

Created attachment 11174 [details]
list is longer then the properties window and thus it is blinking when mouse is over it

Finaly I made 2 snapshots 'cause on 2 of them you see an attempt of
selection a value from the list.... but list is blinking and it is
impossible to choose something.

On the midle one you see list in peace and quiet (mouse is not
pointing on it)... just for an idea what I see on linux...

Blinking?

What window manager are you using?  Looks like a bug in the
JDK code that decides whether a lighweight or heavyweight
popup should be used.

I'm on vacation and can't diagnose it from home (only XP 
installed).  I will attach a patch to force heavyweight
popups under Linux.  Daniel, please try it out - if it 
solves the problem, then we will have diagnosed it.

Also if you could try it unpatched on a different window
manager, that would help a lot in figuring out if it's a
AWT vs. Window manager war or what.

Created attachment 11176 [details]
Patch to force heavyweight popups on Linux

Hello,
I'm using KDE 3.2.1 as my default WinManager.
I'll try it in Gnome (without patch and let you know).

Please, be patient 'cause I must done other stuffs first and
also I'm leaving for my holidays.

Well, I tried apply your patch now, but I'm not able to do it:-(
please, tell me how.

I tried it from NB to patch the ComboInplaceEditor.java where I got a
message:

"No differences found in file combodiff.diff"

Please Martin, if you could look at this and tell me if that's correct
or what's wrong with it.


And also I tried from cmdline:
$> patch -i ./combodiff.diff 
~/cvs/IDE/TRUNK/nb_all/openide/src/org/openide/explorer/propertysheet/ComboInplaceEditor.java
patch: **** Only garbage was found in the patch input.


FYI: I've updated ComboInplaceEditor.java (trunk) and I have r:1.2
after update.

This is diff of a format of an 'ed' script. NetBeans patch algorithm
can not handle that. Tim, please submit a contextual diff instead.

I tested the behaviour under default Gnome on RH9.
The behaviour is good. No blinking.
Under my KDE 3.2.1(I upgrated the newest from kde.org)
there is still problem even with applied patch.

I've copied the patch after line 60 of ComboInplaceEditor.java
and it was compilable. So I created pbinary patch for thi purpose and
I didn't notice any improvement under KDE :-(

Ugh.

Any ideas for how to figure out what window manager someone
is running under Linux?  If not, this may need to be closed.

I could force the heavyweight popups for Linux, since you say
it works for Gnome (was that what you had the problem on?),
but since heavyweight popups are less efficient, it would 
be better to only do this where it's really needed (maybe
a startup line switch?).

But I have no idea what to do about this for KDE, if 
heavyweight popups don't fix it.  I'm guessing that what
is happening is something like:
 1 Popup is created lightweight
 2 Popup won't fit; recreate it heavyweight
 3 Size checked on mouse move; recreate it lightweight
 4 Popup won't fit, goto 2

May be an article of the client property that tells the
combo box that it is a table cell editor?

nb40dev [200308060100] jdk 1.4.2
changing Platform, OS.
It works fine on Windows, Solaris

Can you double check this problem with a recent official release of
KDE?  If yours is a build from source, it may be their bug, not 
ours - it sounds like it probably is.

I've committed the patch to the trunk.  To turn it on, run with

-J-Dnetbeans.ps.combohack=true

That should make it easier to test.  

I also patched the custom
look and feel class for the combo box to log resizes of the combo
popup and print a stack trace.  That should provide all of the
diagnostic feedback we need.  To turn logging on, run with

-J-Dnetbeans.ps.combolog=true

Try it with both switches on the trunk, and if you can still
reproduce the problem, send me the console output with stack
traces from when the editor is flashing.

Thanks Time for the patch (now, part of the build).

I was on my vacation, so I couldn't answer you:-(

--- to KDE:
>Can you double check this problem with a recent official >release of KDE?
Sorry,  I made typo in my version of KDE. It should be 3.1.2!!! (not
3.2.1). BTW:the latest official release of KDE is 3.1.3 (I'll try to
upgrade to this)

>If yours is a build from source, it may be their bug, not 
>ours - it sounds like it probably is.
IMHO: Doesn't make sence that building from sources points to their bug.
But, I installed the RPM packages for RH9.
---


so I will test it and let you know the result...

True, but window manager vs. JDK wars are terribly hard to diagnose.
I recall NetBeans having completely different (but equally unusable)
problems when using FVWM, depending on whether I used the Sun 1.3
or IBM 1.3 - because they were using different graphics calls.

Anyway, if it seems to be KDE specific, we may be able to work
around it somehow, or at least file a bug with them or the JDK.

yap, you're right....

Anyway, I successfully upgraded to the latest official KDE release
3.1.3 and tried with NB40-dev #200308120100

I executed ide with this command:
./runide.sh -J-Dnetbeans.ps.combohack=true -J-Dnetbeans.ps.combolog=true

but I didn't register any atypical outputs to console... :-/
For sureness I'm attaching everything from my console printed till I
shutdown the ide...
I guess there's no interesting output for you...

Did I wrote bad command? Are you sure you committed the patch to the
trunk=NBdev40?

Created attachment 11298 [details]
console output

and the behaviour is still the same: blinking if it's overreach the
borders of a property window

I must admit I can't reproduce it now on todays build with "original"
settings (used day by day till now) and even on #2003-07-28-0100 with
new userdir on which I reported this blinking dropdown list too...

I can't explain it, and I must make big excuse to Tim for spending so
much his time. Sorry Tim, but I didn't lie, why should I did?

Marking as Worksforme

just verifying

Well, I'm able to reproduce the bug on dev build #200309170100 on
Solaris 8. Come by to see it in action. It blinks very quickly when
the popup overreach the main window, it's not possible to select the
desired value.

I can't come look because I'm in California...

Martin, could you run with the line switches I mention earlier in this
issue?  Specifically, see if forcing the popup to be heavyweight cures
the problem, and if possible capture the logging output from the 
logging line switch?  

That will help to find out if what I think is going on is what's going 
on - the combo comes up lightweight, it won't fit, it is converted to
heavyweight, then it will fit, it is converted to lightweight...

Also, could you specify *exactly* what platform/configuration/jdk/etc
you are using?

More questions:
Does the popup come near the edge of the screen?  I'm wondering if the
problem is code that moves the window so it stays on the screen - if it
is wide and the list is on the far right, it will be repositioned.

Does this happen for all combo editors, or only specific properties?

What window manager are you using?

Are there any other applications running at the same time?  Do any 
things outside the JVM have an effect on whether the bug manifests
itself?

I've added another diagnostic option.  Could you do a build and run with
-J-Dnetbeans.ps.standardComboUI=true

(and not netbeans.ps.combohack=true) and see if you can reproduce the
problem?  I would like to determine if the problem is in the interaction
between the table and the combo box, or is a problem in the UI class
I'm using.

And still more logging options:  Could you also try running NetBeans
with only the option 
-J-Dnetbeans.ps.logComboPaints

then reproduce the problem and attach the log file?  It should have
all kinds of stack traces in it from anytime the editor was shown or
repainted, so it should be much easier to see what is triggering the
repainting.

So I've tested it with the switches on the new build #200309180100.
Here's the info:

Product Version       = NetBeans IDE Dev (Build 200309180100)
Operating System      = SunOS version 5.9 running on sparc
Java; VM; Vendor      = 1.4.0_03; Java HotSpot(TM) Client VM
                        1.4.0_03-b04; Sun Microsystems Inc.
Java Home             = /usr/j2se/jre
System Locale; Encod. = cs_CZ; ISO8859-2

Starting system in full screen (MDI) UI mode.

I've run it again without any switches and the behavior is the same.

When switches -J-Dnetbeans.ps.combohack=true
-J-Dnetbeans.ps.combolog=true are used, the behavior is still the same
and nothing is printed into the console not ide.log.

It seems, that the problem is not in resizing, but in repainting. When
the popup is shown, it's visible without problems until you start to
move the mouse above the popup window. You can select the desired item
via keyboard arrows, but as soon as you start to move the mouse
pointer, it's quickly blinking and after a while it collapses.

SDI or MDI mode does not matter, the behavior is the same.

I've tried only the switch -J-Dnetbeans.ps.logComboPaints but again,
the behavior is the same and noting is printed to the console nor
ide.log.

Finally -J-Dnetbeans.ps.standardComboUI=true fix the problem. The
popup window has a scroll bar, but also exceeds the main window
boundary. It displays correctly and does not blink. Only after I start
selecting something it can not be dismissed by ESC and sometimes I
need to click on it twice to get it to expand (when I click on another
combo-box property while one is already expanded).

Hope this helps.

I'm not surprised the standardComboUI option doesn't really work well - 
there are some hooks in CleanComboUI to allow it to work better with
the table (solves a problem with ordering of FocusListeners).

So it's just madly repainting...I wonder if it could be trying to 
display a tooltip?  

-J-Dnetbeans.ps.logComboPaints should at least print something to
stderr when the combo is opened/closed.  Was there really *nothing*
written?

We need to figure out what the call stack is when these repaints
happen - I wish I could reproduce this.

I've added still another logging option:
-J-Dnetbeans.ps.combolog2

(I'm running out of names :-)

which should print a stack trace every time CleanComboUI.paint() is
called.  Try it and there *should* be a stack trace for each repaint,
so we can figure out where the calls are coming from.

Created attachment 11678 [details]
Zipped ide.logs The latest start is with -J-Dnetbeans.ps.combolog2=true -J-Dnetbeans.ps.logComboPaints=true

I've attached all ide.logs that I have. The latest start is with
today's build and -J-Dnetbeans.ps.combolog2=true
-J-Dnetbeans.ps.logComboPaints=true switches.

There are some thread dumps. Hope this helps :-)

Hrm, all of the calls just look like normal repaints when something has
been changed.   So somehow, painting the combo is causing some part
of the window to get invalidated, triggering another paint.  It's very
odd.

I'll be flying back to Prague tomorrow, so maybe we could test some
fixes on one of your machines next week?

Try it today - I added a trivial rendering optimization which might just
cure the problem (it was part of the call stacks in Martin's log).

----litle bit off topic----
2 Tim:
> Was there really *nothing* written?
I must comfirm that all Martin described here, I had exactly the same
problems (as looking what I wrote, I wasn't so exact).
Also nothing was printed into console when I used cmd-line switches...
----e/f off topic----

I've tried it again (build #200309220100) without any options and the
behavior is still the same :-(
Do you want me to generate some logs via
-J-Dnetbeans.ps.logComboPaints=true ?

I'd rather have a look at it in the office.

Something is causing repaints to be posted - all of the repaints
come from the usual AWT event-pumping machinery.  The question is - 
*what* is posting these events.

I have a feeling some painting logic may be making RepaintManager 
think that part of the editor was overpainted, so part of the editor's
surface gets marked as dirty and needing to be repainted (and the
repaint will be initiated on the table, because it's the painting
root.

A couple things that might help diagnose - run with these switches
separately:

Try 
 -J-Dnetbeans.ps.nevermargin=true
This will turn off the painting logic that draws the gray left hand
margin, which is an unusual feature of the table's painting.  See if
the behavior is the same.

Then try
 -J-Dnetbeans.ps.forcetabs=true
This will use tabs instead of expandable sets, turning off the
painting logic that draws the expandable sets.

If neither works separately, try them together - that should turn
off all the strange painting logic in the table;  that should help
narrow down the problem, or at least show where it isn't.

It does not help neither one of them nor both of them together.

IMHO it would help if you would make it to fit on the properties
window always. It could have a scroll bar when it's too long. This
would be a good idea anyway. If there are 100 items, it wouldn't fit
on the screen. Currently when I move the IDE down to the bottom of the
screen, the popup does not fit and it's blinking from the beginning.
It can not draw itself at all.

I've checked how code completion works. It always fits in the Editor
pane however narrow it is. Something similar would help in this case
as well IMHO.

It's actually a bug fix that the combo popup is bigger than the combo
- since the space to display text in the combo box is small, popping
up a combo box with enough space for three characters is pretty silly.

I'll make it work somehow...

FYI, I've found the problem and it's fixed on the PropertyPanel
rewrite branch.

Property panel rewrite branch merged.

Martin, could you please verify or reopen ?
You were the only one that was able to reproduce :) 
thanks.

verifying