This Bugzilla instance is deprecated, and most Eclipse projects now use GitHub or Eclipse GitLab. Please see the deprecation plan for details.
Bug 415675 - [ViewMgmt] Pin-able views cannot be restored at the same location in some cases (in Eclipse Kepler)
Summary: [ViewMgmt] Pin-able views cannot be restored at the same location in some cas...
Status: RESOLVED WORKSFORME
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.3   Edit
Hardware: PC Windows 7
: P3 normal (vote)
Target Milestone: 4.4 M6   Edit
Assignee: Platform UI Triaged CLA
QA Contact: Eric Moffatt CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-08-22 09:22 EDT by Ulrike Hellbrück CLA
Modified: 2014-02-04 13:51 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrike Hellbrück CLA 2013-08-22 09:22:28 EDT
Hello

I have a Problem with my pin-able views: 
they cannot be restored at the same location in some cases.

The problem can be easily reproduced using the search-view: 
- Open 2 view instances and pin both instances.
- Then close the 1. opened view instance.
- Move the left view instance to another area of the perspective 
  (e.g. to the top-right area or the bottom-left area)
- Then close this view instance and reopen it.
-> It is reopened in the view area (bottom right) 
   and not at the location it was moved to.

The problem does not happen when the 2. opened view instance is closed and the 1. opened view instance is moved: it is reopened at the location it was moved to. The problem seems to be related to the view ID: if the secondary view ID is null, then it works, else it does not work.

Thanks
Comment 1 Eric Moffatt CLA 2013-08-28 11:33:37 EDT
I suspect that this is related to another defect that I'm looking at regarding  placeholders with specific secondary id's. This fix for both should be the same; first we should try to find the placeholder for the complete compound id (<ViewId>:<secondaryId>) and if we find it we should treat it as a 'normal' open.
Comment 2 Eric Moffatt CLA 2013-11-05 15:06:59 EST
To me this appears to be working 'correctly' even though I can understand your confusion. If you put a breakpoint in WorkbenchPage#showView(id, secId, mode) and print out the id's of the view that is being opened you can see that the new instances of the Search view increase the value of the secondaryId. This mean that closing the one with the secondaryId of "2" after moving it and then opening another is actually opening a new instance with the secondaryId of "3" so it has to go back where it was.

See bug 409834 which is another example of something similar...
Comment 3 Eric Moffatt CLA 2013-12-10 15:37:55 EST
M4 is done...
Comment 4 Eric Moffatt CLA 2014-02-04 13:51:33 EST
I've just re-verified that the secondaryId always changes in this scenario so the results are actually what should be expected...