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.
Summary: | [41cat] Netbeans does not come to the foreground when debugging | ||
---|---|---|---|
Product: | debugger | Reporter: | hopeless <hopeless> |
Component: | Code | Assignee: | issues@debugger <issues> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | dsimonek, jchalupa, jjancura, jrojcek, jtulach, lleland, vanob |
Priority: | P2 | Keywords: | API |
Version: | 4.x | ||
Hardware: | PC | ||
OS: | All | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | 50921, 56277 | ||
Bug Blocks: | |||
Attachments: |
Simple Swing project (zipped) to reproduce the issue
Proposed fix |
Description
hopeless
2004-08-24 17:46:19 UTC
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. |