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 47825 - [41cat] Netbeans does not come to the foreground when debugging
Summary: [41cat] Netbeans does not come to the foreground when debugging
Alias: None
Product: debugger
Classification: Unclassified
Component: Code (show other bugs)
Version: 4.x
Hardware: PC All
: P2 blocker (vote)
Assignee: issues@debugger
Keywords: API
: 19292 50921 56038 (view as bug list)
Depends on: 50921 56277
  Show dependency tree
Reported: 2004-08-24 17:46 UTC by hopeless
Modified: 2010-04-29 09:18 UTC (History)
7 users (show)

See Also:
Exception Reporter:

Simple Swing project (zipped) to reproduce the issue (10.03 KB, application/octet-stream)
2004-10-20 16:23 UTC, hopeless
Proposed fix (1.46 KB, patch)
2005-03-10 17:13 UTC, Stanislav Aubrecht
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description hopeless 2004-08-24 17:46:19 UTC
[ JDK VERSION : J2SE 1.4.2_04 ]

When debugging a Swing application, Netbeans does not come to the foreground when it hits a breakpoint. This leaves you guessing that you've hit a breakpoint and that your application hasn't just gone a bit slow.  I can't remember what the story was with 3.6 but I thought it came to the front when it hit a breakpoint?

P.S. I'm not sure if debugger is the correct component for this issue.
Comment 1 Jan Jancura 2004-09-08 15:23:24 UTC
I have seen it too, but its probably random. Unless you have some
exact usecase.
Comment 2 hopeless 2004-09-09 11:56:43 UTC
My only use case is the simulation I was trying to debug.  If this is
not a common occurance for all, then I guess it might have something
to do with the way the simulation toolkit (RePast) is programmed, or
any of the 8 other windows it displays.  I'll accept it as 'random',
for now, but there's probably an underlying cause or configuration in
my case - it's just too hard to know what.
Comment 3 jasondonmoyer 2004-10-11 16:59:35 UTC
I see this behavior with the debugger as well (on win XP).  I'm
debugging web apps via JPDA and it always occurs (not random).
Comment 4 vanob 2004-10-20 15:01:41 UTC
I have a webapp project with external tomcat.
I debug via socket attach and IDE never comes to the foreground.
I think someone should remove the keyword RANDOM.
I will raise the priority to P2 because it's a regression
from 3.6 and really makes debugging process unproductive.
Comment 5 hopeless 2004-10-20 15:51:23 UTC
I'm also still getting this behaviour in beta 2 on a completely
different (Swing) application.  I did try writing a v. small test case
but it didn't reproduce the bug so it is not a trivial issue.  

However, it seems for the other commenters that there are problems
with debugging web apps although my experience with this bug has been
with Swing apps.  Perhaps, it is related to winXP, not the project type?

I'm using beta2 on winXP, JDK 5.
Comment 6 Martin Grebac 2004-10-20 15:59:22 UTC
Does the taskbar blink at least, or nothing happens at all when you
hit a breakpoint?
Comment 7 hopeless 2004-10-20 16:10:30 UTC
Nope, I've just tried it.

No blinking or other forms of notification are given.  My current
application is a Swing application which is centered in the screen and
smaller than the NB window (which is maximised).  I'll try (again) to
reproduce it with a small application or otherwise I'll grab a small
screenshot of the current one when it hits a breakpoint.
Comment 8 hopeless 2004-10-20 16:23:26 UTC
Created attachment 18410 [details]
Simple Swing project (zipped) to reproduce the issue
Comment 9 hopeless 2004-10-20 16:25:53 UTC
I've just added a simple Swing application (as a NB4 project dir,
zipped) which reproduces the issue on my PC.  Basically it displays a
small window with a single button.  Place a breakpoint in
testBreakpoint() and debug the application.  Click the button in the
window that appears.  The breakpoint should be reached but NB doesn't
come to the foreground.

I've purpose displayed the window in the same way as my current
application does in case this is the problem.
Comment 10 Jan Jancura 2004-10-21 13:59:22 UTC
Fixed on my side.
Problem remains in WindowSystem. (SHOW_GOTO) should call Window.toFront (), I think. At least
on some platforms like Windows, where you can not have focus in window
which is not active.

Comment 11 David Simonek 2004-10-26 19:41:44 UTC
I would slightly disagree that (SHOW_GOTO) should do the
fronting. AFAIK can be used also in other
situations then breakpoint jumping, where fronting may not be
desirable. Also javadoc says nothing about fronting, so I would say
from API point of view current impl in openide is correct.

I would suggest to implement fronting in debugger directly, only
problematic part is to obtain swing component of editor, probably
through getOpenedPanes method of EditorSupport.

java.awt.Window w =
 // be defensive, although w probably will always be non-null here
 if (w != null) {

I tried mentioned code, it worked, but for some reason only for first
time, I don't know why :-(
Comment 12 Milos Kleint 2004-10-27 06:44:16 UTC
dafe, have you checked that the toFront() call doesn't break the
winsys model/view synchronization?
Comment 13 Jan Jancura 2004-10-27 12:06:57 UTC
Fronting of windows is feature of Window System. I should not do such
things in my code, because I do not know what type of window system I
am running in (single x muti view, ...).
Thats why I can not apply the ugly hot fix suggested by you.

You should fix this bug, or close it as not supported feature.
Comment 14 David Simonek 2004-10-27 16:28:50 UTC
Milos: It shouldn't break now AFAIK, but I'm aware that such calls can
be potentially dangerous.

Jan: Code I posted should work for any winsys type. Anyway I agree
that it's better to manage fronting of windows from inside of window
system. I just wanted to solve this for our users...
Comment 15 David Simonek 2004-10-27 17:53:27 UTC
Summarization: For real fix, debugger needs enhanced API to call to
request window fronting.  I created new openide enhancement 50921 to
track the issue.

I'm passing this issue back to debugger, because the bug itself is
indeed in debugger. However dependence on 50921 shows that it can't be
correctly solved without enhanced API provided by openide.
Comment 16 Jan Jancura 2004-10-29 08:45:34 UTC
*** Issue 19292 has been marked as a duplicate of this issue. ***
Comment 17 hopeless 2004-10-29 10:54:11 UTC
I was wondering, should this still be a P3 bug?  It seems to be a
regression against previous versions of NB and I'd like to see it
fixed before final release of NB4.  I also note that it is marked for
future milestones.  Why?
Comment 18 David Simonek 2004-10-29 11:50:57 UTC
Please don't argue over priority, keep us our right to schedule things
at least...
I made the change because it's not even clear if fronting is good idea
or not. Unix guys are against any fronting (they can have focused
window in background, you know?) so validity of this bug is even
questionable on non-windows systems.

Moreover fixing this issue requires enhanced API on two other places,
which is not fixable in 4.0 either as P2 or P3. Hotfix I suggested
don't work well, so I doubt this can be regression, as we probably
don't know even now how to hotfix this correctly.
Comment 19 hopeless 2004-10-29 11:59:36 UTC
Thanks for your comments.  It is now much clearer to me that the
problem has aspects other than the purely technical ones.  This wasn't
previously clear - I thought it was only a technical issue preventing
this from being fixed.

I wasn't trying to force the priority change or anything but, as the
original reporter, I was concerned about the status of this bug.
Comment 20 vanob 2004-10-29 12:11:02 UTC
I wonder why a developer has to be against
fronting. I'm a linux developer and it's
a REAL pain to debug blindly. Everytime
A servlet hits a breakpoint I want IDE to notify
me and I don't like checking everytime whether IDE 
hit the breakpoint or not.
It's a regression because it has worked in all netbeans releases I've
If you don't have a solution admit it, just don't try 
to convince us that this bug does not matter.

What about prioriy. It's a community not YOU (sun employee) who decide
what is an important issue and what is not. It's really simple
to define the future of this bug. That's why the netcat program exists.

Hope you understand me.
Comment 21 tboerkel 2004-12-09 12:47:03 UTC
Please make this configurable. Under Windows, I think, this is a
Comment 22 Jan Jancura 2005-02-16 12:00:24 UTC
Depends on some enhancement -> switching to enhancement too.
Comment 23 lleland 2005-03-05 23:34:24 UTC
Upgraded to 41cat, P2, and re-defined back to a defect.

Despite the need for new code someone chooses to call "enhancement",
this behavior is fundamental to the proper operation of a debugger.
When you hit a breakpoint, the controlling debugger is handed control
and focus to notify the user of the event. The fact that the NetBeans
debugger has always lacked this event notification leaves the user in
the dark as to why the debugged code is no longer operating, and is
definitely a defect.

As per the Bug Priority Guidelines, this priority of this issue has
been set to P2: "No or inappropriate indication of progress of a
running task".
Comment 24 zikmund 2005-03-07 08:39:28 UTC
*** Issue 56038 has been marked as a duplicate of this issue. ***
Comment 25 Jan Jancura 2005-03-07 10:13:40 UTC
Not fixable on my side - its Window System feature.
Comment 26 David Simonek 2005-03-07 11:14:02 UTC
Jan, you are not right - this is a bug in debugger, even fixable with
hackish workaround (see my path mentioned before). On openide part, we
should provide new API (see issue 50921) to enable you to solve things
in more clear fashion. But this bug is yours, sorry.
Comment 27 Jan Jancura 2005-03-07 12:30:46 UTC
Hack does not work, as you wrote. 

This feature is not supported in our Window System, so I can not fix
it too - closing as wontfix. 
Comment 28 hopeless 2005-03-07 12:43:19 UTC
hang on a second!  

As the original reporter of this bug I've been watching the posts go
back and forth since last year.  We're all software engineers here,
and I can understand the desire to clear as many bugs as possible (and
not to be responsible for those left open) but this is a required
feature.  When debugging an application I *need* some idea that it has
actually hit a breakpoint.  I don't care if this is configurable (come
to front, blink, do nothing) but it has to be available.

I would hate to see this bug filed as WONTFIX simply because the
required infrastructure is not there or because two developers can't
agree on the division of responsibility.  This is a required feature.  
Comment 29 Jan Jancura 2005-03-07 13:06:35 UTC
This issue is about fronting NetBeans main window only. Not about some
other visual feedback. 

Speaking about visual feedback when debugger stops on breakpoint:
- current line is changed in editor
- message is written to optput window
- text written to status line
- all debugger views are refreshed - clall stack update, etc.
So I think that visual feedback is there.

And speaking about fronting of NBMain window. I am not able to fix it
on my side, and our Window System do not support it. So, to be fair, I
should mark this issue somehow if I do not plan to fix it.
Comment 30 vanob 2005-03-07 14:20:23 UTC
I'm not a hardcore netbeans developer but if I were 
I would create another issue addressing Window System ability to do 
focusing of a main window and mark that issue as a blocker of this one.

Please don't ignore our requests.
It's hard to beleive that such a basic functionality is
missing and nobody is willing to fix it. What do QA guys say about that?

Comment 31 lleland 2005-03-09 21:16:07 UTC
While the NetBeans window displays a number of effects upon a breakpoint event,
the window is not activated and brought to the front, so none of these effects
can be seen by the user. A notification that cannot be seen by the user is not a
valid notification.

Windows, (L/U)inux, and OSX all allow a controlling application to request
activation of the main window from a created or debugged application. Since the
NetBeans debugger knows when a breakpoint is hit, it is capable of making this

This simple function is provided by every other debugger, and is a requirement
of the fundamental debugger use case. The full function is in both directions:
The debugger target is activated when started or continued, and the debugger is
activated whenever the target is paused, halted, or ended.
Comment 32 Jan Chalupa 2005-03-09 21:42:47 UTC
Stan, please look at it.
Comment 33 Stanislav Aubrecht 2005-03-10 17:13:01 UTC
Created attachment 20759 [details]
Proposed fix
Comment 34 Stanislav Aubrecht 2005-03-10 17:15:04 UTC
i've tried and slightly enhanced dafe's hack and it seems to be working fine
(latest build + jdk1.4 + winxp). haven't tested on unix/linux yet though.

now we need to agree on some sort of api enhancement (SHOW_TOFRONT) and
'fronting hack' wrapper.
Comment 35 Stanislav Aubrecht 2005-03-22 08:25:55 UTC
*** Issue 50921 has been marked as a duplicate of this issue. ***
Comment 36 Stanislav Aubrecht 2005-03-22 08:32:08 UTC
the window system now supports fronting of top components (e.g. editor) - see
issue #56277.

reassigning back to debugger team to use the new functionality.
Comment 37 Roman Ondruska 2005-03-25 09:24:06 UTC
New API implemented in debugger.
Comment 38 Roman Ondruska 2005-03-29 13:48:16 UTC
From a unix user:
When a breakpoint is hit, the whole IDE window fronts and takes focus.  I think
this is new behavior, and it breaks my workflow. This means that the IDE gets
moved to the current window manager workspace (I'm using gnome), so now both my
debug target and my debugger are sharing the same workspace forcing me to either
go put NetBeans back in its own workspace where I like to keep it, or I need to
switch between the windows using the mouse on the taskbar rather than my fast
workspace switch keys that I've been using up until now.

-> New behavior restricted to MS Win systems.  
Comment 39 vanob 2005-03-29 15:32:27 UTC
I work in linux and my workflow is not broken.
I have both IDE and Target on the same workspace and I don't
experience that problem.
Ideally IDE should focus IDE window in IDE's workspace but for
now at least make optional and don't hardcode the platform restriction. I don't
care it will be a command line switch,
or customizable from the GUI. Just make it as an option and don't take
that fixed bug from me. I've been waiting for it for 2 releases. :)
Comment 40 Jan Jancura 2005-03-29 16:36:53 UTC
I think that current solution is OK. 
Default on Windows -> fronting 
default on Linux -> do not use fronting. 

As far as I know this solution should cover requirements of most of users for
given platforms.
If you would like to customize this default - OK. But this is RFE.
And I do not want to fix it for nb4.1.
Comment 41 vanob 2005-03-30 08:15:55 UTC
Wait for a second.
The initial issue was to fix debugger window fronting 
on all platforms. Now based on ONE user's feedback it's limited
to Windows. I don't have anything against that user but why that user's 
opinion is prefered to mine? With the same success I can tell you that when the
bug is fixed for all platforms it's a correct solution and if it breaks your
workflow just file an RFE. If something breaks his workflow that fixes mine.
So the best solution would be to make it optional.
Is that hard to implement one command line switch like
Comment 42 Jan Jancura 2005-03-30 11:52:21 UTC
I am not prefering one user to another. I am just looking for good defaults for
different platforms. I have speak with more people, and I have listened more

I do not agree that creating more and more options is solution. We should find a
good defaults covering needs of majority of our users. Having tons of options is
not good. We are not able to do testing and keep quality of them, we are not
able to create nice UI customizers, ...

I do not want to create command line options. This is not a good way how to do
things. Its only hack for several users.

We will reconsider creating of some visual option for this purpose for the next
release, based on user feedback.
Comment 43 vanob 2005-03-31 09:25:19 UTC
I guess I'm in the minority now.
Is it possible to take some survey or poll to determine how many people
prefer to have window fronting as the default setting on linux?

BTW I don't think netbeans is bloated with options and some
temporary switch to workaround that problem would ease my life.

I remember the same thing happened with the package view setting (flat,hierarchical)
Comment 44 Jan Jancura 2005-03-31 11:40:14 UTC
OK. I have added it there for you.
Just add:
to your command line. 
Let me know if it works, please.

cvs commit -m "47825 [41cat] Netbeans does not come to the foreground when
debugging" (in directory
Checking in;
new revision: 1.14; previous revision: 1.13
Comment 45 vanob 2005-03-31 12:01:56 UTC
I now use latest q-build.
Will it be integrated in the next one or should I use the daily build?
Comment 46 Jan Jancura 2005-04-01 08:13:35 UTC
You can check daily build, or you can wait for next QBuild - it will be nb41 RC1
Comment 47 Quality Engineering 2010-04-29 09:18:57 UTC
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.