Bug 572598 - Toolbar of a View not created / visible
Summary: Toolbar of a View not created / visible
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.17   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 4.20 M2   Edit
Assignee: Rolf Theunissen CLA
QA Contact:
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2021-04-05 22:51 EDT by Martin D'Aloia CLA
Modified: 2021-05-11 02:32 EDT (History)
2 users (show)

See Also:


Attachments
Toolbar buttons of View not shown (282.35 KB, image/png)
2021-04-05 22:51 EDT, Martin D'Aloia CLA
no flags Details
Toolbar buttons of View properly shown (291.60 KB, image/png)
2021-04-05 22:51 EDT, Martin D'Aloia CLA
no flags Details
Bug demo using 2021-03 (4.19) (972.94 KB, image/gif)
2021-04-05 22:55 EDT, Martin D'Aloia CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Martin D'Aloia CLA 2021-04-05 22:51:14 EDT
Created attachment 286032 [details]
Toolbar buttons of View not shown

If the same view is opened on 2 perspectives at the same time and you reset one of them then the ToolBar of a View is not created (or not visible / hidden) when you reopen it.

It is replicable with several views (e.g. Error Log, Expressions, Breakpoints, Git Repositories).

It is not replicable on Eclipse 4.16.
It started on 4.17 and occurs also on 4.18, 4.19 and 4.20 I20210405-1800.

Using CSS Spy it seems to not be even created / added to the parent Composite (see toolbar-missing.png) compared to when it is shown (see toolbar-visible.png)


# Steps to reproduce:

1. Download a Eclipse IDE for Java Developers (4.17, 4.18, 4.19, 4.20 (Integration Build currently))
2. Open it
3. Add 'Debug' perspective
4. Open 'Error Log' view (see that toolbar has buttons / icons)
5. Go back to the 'Java' perspective
6. Open 'Error Log' view (see that toolbar has buttons / icons)
7. Reset the perspective
8. Open 'Error Log' view (see that toolbar does not have buttons / icons. Idem on 'Debug' perspective)

To retest it you can:

1. Reset 'Debug' perspective
2. Reset 'Java' perspective
3. Starting from 'Java' perspective execute steps 3 (Go to perspective, instead adding it) to 8


# Possible similar to/caused by/related to the following bugs:

Bug 564290 (Very similar)

Bug 317623 (Probable cause 1)
Bug 90757 (Probable cause 2)
Bug 562892 (Probable cause 3)

Bug 565946 (Maybe related)
Bug 566375 (Maybe related)


# Environments / Builds tested

Eclipse IDE for Java Developers (includes Incubating components)
Version: 2020-09 (4.17.0)
Build id: 20200910-1200
OS: Windows 10, v.10.0, x86_64 / win32
Java version: 11.0.4

Eclipse IDE for Java Developers (includes Incubating components)
Version: 2020-09 (4.17.0)
Build id: 20200910-1200
OS: Linux, v.5.4.0-26-generic, x86_64 / gtk 3.24.18, WebKit 2.28.1
Java version: 11.0.10

Eclipse IDE for Java Developers (includes Incubating components)
Version: 2020-09 (4.17.0)
Build id: 20200910-1200
OS: Mac OS X, v.10.15.7, x86_64 / cocoa
Java version: 11.0.10

Eclipse SDK
Version: 2021-06 (4.20)
Build id: I20210405-1800
OS: Mac OS X, v.10.15.7, x86_64 / cocoa
Java version: 11.0.10
Comment 1 Martin D'Aloia CLA 2021-04-05 22:51:59 EDT
Created attachment 286033 [details]
Toolbar buttons of View properly shown
Comment 2 Martin D'Aloia CLA 2021-04-05 22:55:22 EDT
Created attachment 286034 [details]
Bug demo using 2021-03 (4.19)
Comment 3 Rolf Theunissen CLA 2021-04-06 08:09:10 EDT
The root cause of this bug is: When resetting the perspective all the widgets of the part-stacks are disposed, including the toolbars of the shared-parts. Before the changes of Bug 562892, the toolbars were re-created when the shared part became active again which hide the problem.

Fix for this issue is to unhook the shared toolbars from the tabfolder before disposing the tabs. A patch will follow.
Comment 4 Eclipse Genie CLA 2021-04-08 14:11:55 EDT
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.ui/+/179050
Comment 5 Rolf Theunissen CLA 2021-04-09 07:13:57 EDT
To better understand what is going on.

Roughly the following happens in WorkbenchPage#resetPerspective:
1. Gather all dirty and to-be-saved parts
2. Ask if save is needed
3. Call modelService.resetPerspectiveModel
4. Create (new) dummy perspective & populate & hide global placeholders
5. Copy the children of the dummy perspective to the real perspective (line 3432- 2436)
6. Clean out the old children of the real perspective (line 3438-3442)
7. Copy new windows from the dummy to the real perspective 
8. Remove old windows from real perspective
9. Reset actions sets
10. Replace tags in real perspective with tags from dummy perspective
11. Reset presentation engine tags
12. Reactivate the real perspective

For this particular bug is triggered in step 6. The old PartSashContainer in the perspective is set toBeRendered = false. As a result of this, all placeholders in the new PartSashContainer are resolved to the parts (not sure how this happens exactly). This moves all widgets to the new PartSashContainer. 

For shared parts that are no longer in the perspective, this move does not happen. As a result, the toBeRendered false will trigger childRemoved and disposeWidget all elements still in the PartSashContainer. ElementReferenceRenderer.disposeWidget ensures that the shared parts are not disposed when they in use in other perspectives. However, this does not take care of the toolbars. Toolbars for parts are drawn by the StackRenderer. Currently, the StackRenderer does not unhook the toolbars when unrendered (i.e. visible = false for the toolbars). Therefore, the toolbars are disposed when the CTabFolder is disposed.

The Gerrit calls a recursive hide on all elements in the PartSashContainer before disposing the widgets, this removes the toolbars from the CTabFolder and prevents the early disposal of the toolbars.
Comment 6 Martin D'Aloia CLA 2021-05-05 13:47:22 EDT
Hi! was there any progress on the review?
(I see that there is a merge conflict now)

It would be nice to have it for 4.20, is it still planned for it?

Thanks!
Comment 7 Rolf Theunissen CLA 2021-05-06 03:03:23 EDT
(In reply to Martin D'Aloia from comment #6)
> Hi! was there any progress on the review?
> (I see that there is a merge conflict now)
> 
> It would be nice to have it for 4.20, is it still planned for it?
> 
> Thanks!

Still working on it, I am not completely happy with the current solution, but it might be the only working low-risk. Also there is a small bug in it now. Other options require a major cleanup/restructuring of the renderers. I will try to make an update and do some more testing to get it in for 4.20