Bug 551171 - Views with secondary ids recreated on perspective change
Summary: Views with secondary ids recreated on perspective change
Status: VERIFIED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.8   Edit
Hardware: All All
: P3 major with 1 vote (vote)
Target Milestone: 4.15 M1   Edit
Assignee: Kalyan Prasad Tatavarthi CLA
QA Contact:
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2019-09-17 18:58 EDT by Mark Allan CLA
Modified: 2020-01-08 04:24 EST (History)
5 users (show)

See Also:


Attachments
RCP Test Case for bug (66.16 KB, application/x-zip-compressed)
2019-12-04 14:49 EST, Joshua Slack CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Allan CLA 2019-09-17 18:58:26 EDT
Views with secondary IDs are creating new instances for each perspective instead of the same instance being reused when the perspective changes. Views without a secondary ID are reused as expected. 

Our application has multiple views with secondary ids that we need to be the same instance of the view across multiple perspectives. This was the behavior until at least Oxygen, but in 2019-03 and 2019-06, new views are created for each perspective. 

Additionally, those views with secondary ids are only listed in IWorkbenchPage.getViewReferences() for the perspective that first shows that view. I.e., if I have two perspectives that add "com.foo.MyView:0", iterating over IWorkbenchPage.getViewReferences() will show com.foo.MyView in the list. After switching to the second perspective, a new MyView is created and visible in the perspective, but when iterating over IWorkbenchPage.getViewReferences() no com.foo.MyView is in the list. Until at least Oxygen, getViewReferences() would have references to all views that are visible in the current perspective.
Comment 1 Rolf Theunissen CLA 2019-11-26 04:26:15 EST
This is a regression of Bug 516403.
Comment 2 Andrey Loskutov CLA 2019-12-04 10:02:30 EST
Mark, could you please provide a simple project (or even better a small test) demonstrating the issue? 

Looks like a bad regression (views aren't supposed to be re-created, that could lead to strange memory leaks / behavior). 

Simeon, I vaguely remember we had some fun with getViewReferences() behavior change after switching to Eclipse 4.x. Could be related to this one may be? I believe we had a bug or two reported?
Comment 3 Simeon Andreev CLA 2019-12-04 10:10:17 EST
We reported bug 525387 and bug 525298. I'm not sure either is related (though the latter almost certainly isn't).
Comment 4 Joshua Slack CLA 2019-12-04 11:00:06 EST
I work with Mark and recently analyzed the behavior he reported here.  The issue appears to be triggered by calls to IPageLayout.addView we are making in the createInitialLayout method of an IPerspectiveFactory.

The main eclipse MWindow (TrimmedWindowImpl) has a List of "sharedElements" of type MUIElement.  This appears to include the elements we have in our perspective view.  When setting up a perspective (or resetting it) we add our 3D view with a secondary ID, such as "xxx.yyy.zzz:0;test".  From here, the Eclipse code goes to create a "SharedPart" MPlaceholder (see org.eclipse.e4.ui.internal.workbench.PartServiceImpl.createSharedPart).  Here it sees the id has a secondary part, so it truncates that part and adds a * instead (e.g. "xxx.yyy.zzz:*").  Then it looks into the window's list of sharedElements and tries to match based on this newly truncated id.

Unfortunately, all of these sharedElements have their original id, so nothing matches.  It then goes on to create a new part of the correct type, replaces the id with the unaltered one, and adds it to the Window's list, growing the list every time you reset the perspective.

Thus, the view is not shared appropriately.  For similar reasons, the getViewReferences is not able to find these unshared copies because they do not match the values held by WorkbenchPage's viewReferences field.
Comment 5 Andrey Loskutov CLA 2019-12-04 11:04:06 EST
(In reply to Joshua Slack from comment #4)
> I work with Mark and recently analyzed the behavior he reported here.

@Joshua: do you have an idea for the patch? If yes, could you push a Gerrit patch please? See https://wiki.eclipse.org/Platform/How_to_Contribute
Comment 6 Joshua Slack CLA 2019-12-04 11:14:12 EST
A patch would either be a rollback of the commit linked in Bug 516403 or somehow incorporate a fix for that as well.  I do not fully understand the issue in that bug report though, so I hesitate to offer a patch. It seems like they were fixing a special case where the secondary id is *... which on first glance looks like a wildcard to me, but it is used in a String.equals call so...
Comment 7 Joshua Slack CLA 2019-12-04 14:49:16 EST
Created attachment 280866 [details]
RCP Test Case for bug

Simple RCP example showing the secondary ID bug.  Run example under Eclipse Photon or newer (I wrote it using 2019-09).

Each perspective has one view using only a primary id and one view using primary id + secondary id.  The secondary id used in each perspective is the same.

View each perspective and run the "File->List Views" command.  Due to this bug, you will see 2 views in the first perspective you open and 1 view in the other.  If you reset a perspective, it will likely then only list 1 view.

Also note the contents of .metadata/.plugins/org.eclipse.e4.workbench/workbench.xmi. After resetting the perspectives and closing the test app, this file adds additional serialized copies of a basic:Part.
Comment 8 Eclipse Genie CLA 2019-12-31 01:09:08 EST
New Gerrit change created: https://git.eclipse.org/r/155115
Comment 9 Kalyan Prasad Tatavarthi CLA 2020-01-02 05:05:32 EST
https://git.eclipse.org/r/155115 and
https://git.eclipse.org/r/#/c/155137 have been merged to master.
Comment 10 Kalyan Prasad Tatavarthi CLA 2020-01-08 04:24:41 EST
verified in the build : I20200107-0600