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.
To reproduce: 1. execute a web module without compiling all the JSPs. 2. bring up the HTTP monitor window and front it. 3. using the browser (not the IDE) make a request for a JSP which initates compilation. 4. the IDE window fronts itself over the monitor window. I see this in 3.4 also. Possible causes might be that the compiler node shows in the execution view, and that things get printed to the log file (jsp:init). Perhaps these actions cause the IDE window to request focus?
I filed it as a P2 because it's a major usability pain for the monitor - you have to rearrange your windows in such a way that it's easy to refront the monitor window.
I'll look at it
Problem is in output window - if you undock OW (Window -> Frame Resides -> As Separate Window), HTTP Monitor will stay in front of IDE, only OW fronts itself. Only think we can do is to not use OW there, which I cannot imagine. I suggest to WONTFIX this issue and dock HTTP Monitor window to some mode instead (e.g. as Tor suggested on nbdev, subject "window fronting issue in MDI mode"). Anyway, there is also the second problem with using it as separate frame - opening dialogs from.
Ales, I have the same problem even if I dock the monitor window into the Output window - the fronting means it gets lost there also! And this doesn't affect only the monitor, but anything you do, either with a separate frame or in the output window. If for example the developer is using the monitor to replay request, I want that tab to stay fronted. But every time a JSP is compiled or a file writes something to the tomcat log files, those tabs are fronted instead. Likewise, if your main focus is the context log file because your application is writing debugging info there, the compilation tab will steal the focus from that also. So in my opinion, the focus request is a bigger problem that we need to look into. I'd like to reopen this one, if it's OK with you.
Ana, I don't think that reopening this issue can solve something there. Moreover, I don't think this issue blocks #31046. At first, you probably tried to dock monitor in output window -> Center, right? You should dock it to Top, then no other OW tab can be fronted over monitor. Or maybe output window isn't right place to dock monitor into - because this is just OW, which makes problems here. What about dock it to Editor -> Bottom? We spent some time with Jano Rojcek (from Prague's HIE) trying to find some good solution there, but for Nevada (short time) we didn't find anything else than docking. Anyway, IMO this is the issue for HIE team to find proper place for HTTP monitor.
Discussion with Ana and Jano on this issue. A new windowing system is being proposed that could solve this issue, however, it is unclear as to when this will be implemented. The back up plan is to keep the HTTP Monitor in the output window, which requires that other windows don't front everytime there is an update, so reopening this issue.
Changing the type to enhancement and Target Milestone to 4.0. Ana, can you add the dependency on the task associated with creating new windowing system.
Ales, I reassign this back to you, because I believe something went wrong when the bug was reopened. I'm afraid it's in the wrong category (this happens when anything writes to the output window), but I'm not sure whether openide is right so I leave that to you. Also, if it shouldn't be assigned to you, perhaps Jan knows who? Pavel Suk, I believe it was you who changed it to an enhancement. I think you got it confused with another issue (31046, the one that is blocked) which says that the monitor should be docked into another component. This is a separate issue. It's currently assigned to Ann S so that she can figure out where it should be docked, which is non-trivial :) The problem described here is more general focussing problem which affects any window that is separate from the main IDE window in MDI. Say that you have the options tab open - it will get hidden also. That the IDE main window fronts itself based on actions that were *not* initiated from that window is definitely a bug and not an enhancement.
Sorry Ana but reassigning to Ales is not a good idea since he is not involved in this project now.
Apologies for reassigning this to Ales - I got confused which Ales was which... After discussing with Petr Jiricka, he suggested just assigning it to the openide module. So we have two symptoms/problems: 1. This is internal inside the output window, and is related to different tabs fronting themselves. If I have multiple tabs in the output window (for example, I have one window for compiler output and a couple of others for different logfiles on the server), then it is practically impossible to track what is written to a log file in real time, because if something is written to another log file, or if something is compiled, then the other tab is fronted. 2. This is external, in that it causes the whole IDE main window to be fronted in MDI: If you were using another, non-modal dialog (for example options, or the HTTP monitor), then if something is written to an output tab, the IDE window fronts itself. Note that during J2EE development, it's not unusual that tasks that are performed from a diffent window cause something to be written to the logfiles. See above for details on how to reproduce.
New winsys is in main trunk. You can check its behaviour. In old winsys NB 3.5 there was 2 issues: 1.When process was executed Execution view was opened in Output window. It transfers focus to Execution view. This is changed in new winsys: When view (TopComponent) is opened focus is not transferred to it. 2.When client code start to write to some output tab it calls InputOutput.select(). Call of select() calls requestFocus() on given tab when it is not compiler tab (regardless value of InputOutput.setFocusTaken(), actually value of setFocusTaken() is ignored in current OutputView (and old OutputTabTerm) implementation. After discussion with Jano: InputOutput.select() should select tab inside OutputView but it should not change z-order of OutputView ie. when there is for example another view in the same mode and OutputView is behind this view OutputView will stay hidden behind this view. (It means that also z-order of main window will stay unchanged.)
This should be fixed in current dev build. When new output tab is created (opened) or existing tab is selected no requestFocus() or toFront() is called ie. main window will not be fronted.
verified 200402251900