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.
[dev-200301190100, Sun JDK 1.4.1_01, MDI] Steps to reproduce: 1. Started w/ a clean userdir 2. In the examples folder created two files: 1 - Hello as Java Main class 2 - MyFrame as GUI Forms | JFrame 3. Opened both source files, the order of Editor panes in the Editing workspace was Hello, MyFrame 4. Saved and compiled Hello. 5. Added a breakpoint to Hello via Shift-F8 6. Started Debugging via Alt-F5 7. The IDE switched to the Debugging workspace and the debugger stopped at the breakpoint. 8. The order of Editor panes in the Debugging workspace was MyFrame, Hello Expected behavior: the order of editor panes should be exactly the same on all workspaces
This is very hard to fix for current window system. Well I'm almost tired to try to explain it, because it is so complicated. The TopComponents are added to modes in separated tasks, if the task is triggered by API call, there is no information about orderWeight (its just internally used for persistence) thus it depends in which order are the TopComponents added. Another problem is that the openedTopComponents (and thus their order) aren't kept in Mode but in its container which is GUI component, actuall adding to GUI componenets could be performed in another order than order in which are TopComponents docked into the mode. This exactly occures in this case. Reason why it can occure, is because the separate tasks are put into DeferredPerformer which pauses a couple of tasks when the window system is doing workspace switch (for our case), and tasks which came later, but the state was already changes are this way probably rescheduled into AWT sooner. The above sentence may not be true, since the actuall adding into the container depends on more factors and flags, which setting could depend on multiple levels of rescheduling. In sum, there occures more request for docking of that component (from more parts, not just CloneableEditor.openOtherEditors like I expected). And the order depend on which requests succed to be performed first when the state becomes ready -> and that is almost like a race condition. Investigating...
Why is this P2? Does not sound like a critical problem to me, more like a usability bug / minor annoyance.
I find it quite annoying and consider it a regression from 3.4.x. However, I'm not so sure about the latter now. Changing to P3 until confirmed.
This comment is a bit out of topic: BTW. Is each regression supposed to be P2 and higher? I think that's wrong. On the other hand, this isn't a regression, winsys works the described way from its benining, and it is just and accident (-> that kind of race condition) that this issue occures after this steps. I believe this kind of problem could be found also in older releases, however probably after another steps.
I would like to add that this problem now seems to occur between restarts. I find that I use NB for long periods of time and get used to where files are in the tab order in the editor. When I restart and they're in completely different order, it's frustrating, although not at the P2 level.
Because Window System v1 will not be supported from now by our team, all old winsys issues (now "core/window system v1" issues) are going to be closed as WONTFIX. Changes in API which emerged both from UI spec and problems with adjusting to the older API are described in the document http://core.netbeans.org/windowsystem/changes.html. It shows also recommends how the client code should be adjusted to the new window system. If you think this issue apply also to the new winsys then change the subcomponent (to "core/window system") and REOPEN it.
issue doesn't apply to new window system - verified