I have seen it too, but its probably random. Unless you have some
exact usecase.

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.

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).

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.

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.

Does the taskbar blink at least, or nothing happens at all when you
hit a breakpoint?

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.

Created attachment 18410 [details]
Simple Swing project (zipped) to reproduce the issue

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.

Fixed on my side.
Problem remains in WindowSystem.
Line.show (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.

I would slightly disagree that Line.show (SHOW_GOTO) should do the
fronting. AFAIK Line.show(SHOW_GOTO) 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 =
javax.swing.SwingUtilities.getWindowAncestor(editor.getComponent());
 // be defensive, although w probably will always be non-null here
 if (w != null) {
    w.toFront();
}

I tried mentioned code, it worked, but for some reason only for first
time, I don't know why :-(

dafe, have you checked that the toFront() call doesn't break the
winsys model/view synchronization?

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.

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...

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.

*** Issue 19292 has been marked as a duplicate of this issue. ***

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?

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.

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.

David
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
seen.
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.

Please make this configurable. Under Windows, I think, this is a
must-have.

Depends on some enhancement -> switching to enhancement too.

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".

*** Issue 56038 has been marked as a duplicate of this issue. ***

Not fixable on my side - its Window System feature.

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.

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. 

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.  

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.

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?

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
request.

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.

Stan, please look at it.

Created attachment 20759 [details]
Proposed fix

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.

*** Issue 50921 has been marked as a duplicate of this issue. ***

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.

New API implemented in debugger.

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.  

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. :)

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.

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
debugger.window.fronting?

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
arguments.

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.

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)

OK. I have added it there for you.
Just add:
 -J-netbeans.debugger.fronting=true
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" EditorContextImpl.java (in directory
C:\Hanz\Dev\trunk\debuggerjpda\ant\src\org\netbeans\modules\debugger\projects)
Checking in EditorContextImpl.java;
/cvs/debuggerjpda/ant/src/org/netbeans/modules/debugger/projects/EditorContextImpl.java,v
 <--  EditorContextImpl.java
new revision: 1.14; previous revision: 1.13
done

Thanks.
I now use latest q-build.
Will it be integrated in the next one or should I use the daily build?

You can check daily build, or you can wait for next QBuild - it will be nb41 RC1
probably.

Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.