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 121218

Summary: Files opened in random tab positions
Product: platform Reporter: Jesse Glick <jglick>
Component: Window SystemAssignee: mslama <mslama>
Severity: blocker CC: gord, hmichel, mentlicher, saubrecht, tmysik
Priority: P3    
Version: 6.x   
Hardware: All   
OS: All   
Issue Type: DEFECT Exception Reporter:

Description Jesse Glick 2007-11-05 19:41:55 UTC
For recent dev builds - perhaps the last week or two? - when I open new tabs in the editor using Alt-Shift-O or
Versioning > History, sometimes they are opened as the last tab as I would expect; but sometimes they are opened as the
first tab instead, or if some files have already been opened in first position, after them. Ctrl-O and Ctrl-B always
seem to open files as the last tab, as does Versioning > Diff. I can't find the pattern.

Ubuntu, JDK 6.
Comment 1 Stanislav Aubrecht 2007-11-06 15:45:46 UTC
i can't reproduce (on winxp)

are you sure it wasn't just a case when the file had been already opened and the editor tabs just scrolled to make it
Comment 2 Jesse Glick 2007-11-06 17:00:34 UTC
Yes, these were newly opened files.
Comment 3 Jesse Glick 2007-11-07 11:26:15 UTC
I was wrong about Ctrl-B never doing this. I had only open and pressed Ctrl-B on line 378 ("return
fileObj.isReadOnly();"). Opened in a tab before 071106.
Comment 4 Tomas Mysik 2007-11-16 16:32:22 UTC
Exactly the same problematic behaviour for me as well.
Alt+Shift+O -> project.xml -> opened as the third tab (5 tabs opened).

Product Version: NetBeans IDE 6.0 RC1 (Build 200711131200)
Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05
System: Linux version 2.6.23-gentoo-r1 running on i386; UTF-8; cs_CZ (nb)
Comment 5 mslama 2007-11-19 11:33:27 UTC
Probably caused by fix of issue #101700. See issue #85666 for more details (my last comment).
Comment 6 mslama 2007-11-19 11:57:23 UTC
Reason is there are 2 contradictory requirements:
1.Someone wants components to *remember* their position after they are closed (it applies to TC with persistence type
only opened (editors) and non persistent. See issue #101700.
2.Someone wants components *NOT to remember* their position after their are closed.

The things is complicated by fact that if TC instance is gc'ed, new TC is created and it is opened in last tab. If
editor reuses TC it is now opened in remembered position. One solution would be: If you want editor to be opened in new
position create new TC ie. do not reuse already existing TC. Question is: When reusing existing TC is correct and when
not? (Similar solution could be implemented in winsys. But I have no idea what is 'correct' behavior in given moment/for
given TC instance. I am afraid at this moment I cannot make happy all.

Possible solution would be to extend TC persistence type to cover this. It would be API change.
Comment 7 mslama 2008-02-20 17:11:04 UTC
*** Issue 123894 has been marked as a duplicate of this issue. ***
Comment 8 Jesse Glick 2008-02-20 20:22:13 UTC
This is still broken.

Perhaps the fix of issue #101700 can be modified to ignore TCs in the editor mode? Or to only remember that they are in
the editor mode, not where?
Comment 9 mslama 2008-02-20 20:46:37 UTC
I was thinking about adding client property to TC. Question is what should be default behavior ie. when property is not
set. Probably keeping old behavior as default makes life easier (editor TC need not change anything and reporters of
#101700 will add client property to their TC).
Comment 10 Stanislav Aubrecht 2008-03-25 14:03:19 UTC
*** Issue 130434 has been marked as a duplicate of this issue. ***
Comment 11 mslama 2008-03-27 14:32:46 UTC
Fixed in main trunk: 8390ee768f34

New client property is added to TopComponent to control behavior when non persistent TopComponent is closed. When
boolean client property KeepNonPersistentTCInModelWhenClosed is set non persistent TC is kept in model when TC is
closed. If property is not set (== null) then TC is removed from model ie. it is original behavior before fix of issue

Added description of client property to arch document: 6beae359cbe2
Comment 12 Martin Entlicher 2008-03-27 18:22:21 UTC
I've added the property to all debugger views:
The behavior of debugger components seems to be fine.
Comment 13 Jesse Glick 2008-03-31 17:21:25 UTC
apichanges says:

"If client property is set (!= null) then TopComponent is kept in model."

In fact the code seems to behave this way as well:

if (tc.getClientProperty(Constants.KEEP_NON_PERSISTENT_TC_IN_MODEL_WHEN_CLOSED) != null) {...}

This is confusing. The constant is documented as a boolean property. Should rather be

"If the client property is set (to true) then the TopComponent is kept in the model."

if (Boolean.TRUE.equals(tc.getClientProperty(Constants.KEEP_NON_PERSISTENT_TC_IN_MODEL_WHEN_CLOSED))) {...}

i.e. null should be treated the same as false.
Comment 14 mslama 2008-03-31 19:46:43 UTC
Ok I will fix it.
Comment 15 mslama 2008-04-02 12:22:41 UTC
Fixed in main trunk: 1f4adeaecfce.