Bug 528152 - E4 view toolbar disappears after application crashes/is terminated
Summary: E4 view toolbar disappears after application crashes/is terminated
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.7   Edit
Hardware: PC Windows 7
: P3 normal with 3 votes (vote)
Target Milestone: 4.13 M3   Edit
Assignee: Rolf Theunissen CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 509371
Blocks: 549902
  Show dependency tree
 
Reported: 2017-12-05 08:42 EST by Christian B. CLA
Modified: 2019-11-27 09:14 EST (History)
5 users (show)

See Also:


Attachments
View with toolbar normal and broken; Preference spy window with and without toolbar. (86.06 KB, image/png)
2017-12-05 08:42 EST, Christian B. CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian B. CLA 2017-12-05 08:42:30 EST
Created attachment 271781 [details]
View with toolbar normal and broken; Preference spy window with and without toolbar.

Views defined by an E4 part descriptor loose their toolbar when the application is not closed nominally with an automatic workbench state save present. E4 spies shows that the toolbar is gone entirely. Restarting the application won't bring the toolbar back. Only clearing the persisted state or deleting the faulty view from the model will restore the toolbar when the view is created anew.
Views using the compatibility layer are unaffected by this.

Steps to reproduce:
- Install E4 spies
- Open the preference spy. Toolbar should be visible
- Wait for the workbench state to be saved automatically (<workspace path>\.metadata\.plugins\org.eclipse.e4.workbench\workbench.xmi). Delay can be lowered in the settings
- Terminate eclipse with task manager (or something similar)
- When restarting eclipse, the toolbar will be gone.

Eclipse version is Oxygen.1a.
Comment 1 Thomas Haber CLA 2018-05-04 02:43:43 EDT
Hi Chrsitian,

i'm facing the same problem with my new e4 plugins.
Did you find a workaround ?

thanks,
thomas
Comment 2 Christian B. CLA 2018-05-09 05:36:36 EDT
I did find a workaround. For our application it comes down to two cases: Normal part and shared part. For a normal part the following code should bring the toolbar back

MPart part = partService.findPart(PART_ID);
if (part != null) {
	List<MToolBarElement> toolbarItems = part.getToolbar().getChildren();
	if (toolbarItems.isEmpty()) {
		partService.hidePart(part, true);
	}
}
part = partService.showPart(PART_ID, PartState.ACTIVATE);

For shared parts, that are made visible by a placeholder, things become slightly more complicated. hidePart, by design, only removes the placeholder. Deleting the broken view from the model has to be done manually by deleting it from the list of shared parts. Then the shared view and the placeholder have to be recreated

// Recreate view if toolbar is broken
MPart part = partService.findPart(PART_ID);
if (part != null) {
	List<MToolBarElement> toolbarItems = part.getToolbar().getChildren();
	if (toolbarItems.isEmpty()) {
		// The actual view is stored as a shared element and can only be deleted manually
		List<MUIElement> elements = modelService.getTopLevelWindowFor(part).getSharedElements();
		ListIterator<MUIElement> iterator = elements.listIterator();
		while (iterator.hasNext()) {
			MUIElement muiElement = iterator.next();
			if (PART_ID.equals(muiElement.getElementId())) {
				iterator.remove(); // view found, remove it.
			}

		}
		partService.hidePart(part, true); // this removes the placeholder
		MPlaceholder sharedPart2 = partService.createSharedPart(PART_ID);
		// Create a new shared part. The returned placeholder only serves as a temporary handle to get the
		// shared view
		MUIElement partPartNew = sharedPart2.getRef();

		// Find the bottom part stack where the view is located by default
		MPartStack partStack = (MPartStack) modelService.find(BOTTOM_FOLDER_ID,
			application);
		// Create a new placeholder for the view in the bottom part stack
		MPlaceholder placeholder = modelService.createModelElement(MPlaceholder.class);
		placeholder.setElementId(PART_ID);
		placeholder.setRef(partPartNew);
		partStack.getChildren().add(placeholder);
	}
}
partService.showPart(PART_ID, PartState.ACTIVATE);

These solutions were found with E4 spies and some trial and error. So far we haven't experienced any issues with the workarounds. There isn't much documentation on this part of E4 so I don't know how it is meant to be done. I can only go by what works for me.

Good luck.
Comment 3 Thomas Haber CLA 2018-05-11 05:19:03 EDT
Hi Christian,

thanks for this, It helped me to understand the mechanisms behind.
By chance, i found another workaround :-)
The problem does not occur if using ToolbarContributions instead of a Toolbar in a PartDescriptor (empty toolbar + contribution).
This also resolves the problem of updated PartDescriptors (addititional menu+toolbar elements) that get not snyced with the part.

thanks,
thomas
Comment 4 Eclipse Genie CLA 2019-08-09 18:39:40 EDT
New Gerrit change created: https://git.eclipse.org/r/147397
Comment 5 Rolf Theunissen CLA 2019-08-09 18:48:49 EDT
(In reply to Thomas Haber from comment #3)

> This also resolves the problem of updated PartDescriptors (addititional
> menu+toolbar elements) that get not snyced with the part.

Can you open another bug for this issue?
Comment 6 Lars Vogel CLA 2019-08-15 16:39:20 EDT
Please add the bug in which you marked the menu and toolbars as not to be persist as dependent bug of this one.