Community
Participate
Working Groups
Created attachment 271940 [details] An example plugin, with a status line contribution, to reproduce the problem with. Steps to reproduce: 1. Import attached plug-in. 2. Start Eclipse in a new workspace. 3. Observe that the status line contribution is at the bottom left. 4. Restart Eclipse in the same workspace. 5. Observe that the status line contribution is at the bottom right. Only the first start in the workspace puts the contribution at the bottom left. Every next start is OK. Our application uses the status line toolbar for some status reporting. Its very confusing to see it to the left every now and then. Seen on RHEL 7.2 with GTK3.14, as well as on Windows 10. Eclipse build: Eclipse SDK Version: Photon (4.8) Build id: I20171217-2000
Created attachment 271941 [details] Screenshot showing contribution at bottom left on first start.
Created attachment 271942 [details] Screenshot showing contribution at bottom right after restart.
On the first execution, the toolbar contribution is created before any other element at the bottom. On the second, third, etc. execution, the rest of the elements are created before the toolbar contribution. E.g. when creating the status line, the first execution has stack: Thread [main] (Suspended (breakpoint at line 269 in StatusLine)) StatusLine.<init>(Composite, int) line: 269 StatusLineManager.createControl(Composite, int) line: 100 StatusLineManager.createControl(Composite) line: 86 StandardTrim.createStatusLine(Composite, MToolControl) line: 127 StandardTrim.createWidget(Composite, MToolControl) line: 45 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 MethodRequestor.execute() line: 55 InjectorImpl.processAnnotated(Class<Annotation>, Object, Class<?>, PrimaryObjectSupplier, PrimaryObjectSupplier, ArrayList<Class<?>>) line: 1002 InjectorImpl.internalInject(Object, PrimaryObjectSupplier, PrimaryObjectSupplier) line: 136 InjectorImpl.internalMake(Class<?>, PrimaryObjectSupplier, PrimaryObjectSupplier) line: 411 InjectorImpl.make(Class<T>, PrimaryObjectSupplier, PrimaryObjectSupplier) line: 344 ContextInjectionFactory.make(Class<T>, IEclipseContext, IEclipseContext) line: 214 ReflectionContributionFactory.createFromBundle(Bundle, IEclipseContext, IEclipseContext, URI) line: 108 ReflectionContributionFactory.doCreate(String, IEclipseContext, IEclipseContext) line: 74 ReflectionContributionFactory.create(String, IEclipseContext, IEclipseContext) line: 51 ToolControlRenderer.createWidget(MUIElement, Object) line: 126 PartRenderingEngine.createWidget(MUIElement, Object) line: 992 PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 661 PartRenderingEngine.safeCreateGui(MUIElement) line: 767 PartRenderingEngine.access$0(PartRenderingEngine, MUIElement) line: 738 PartRenderingEngine$2.run() line: 732 SafeRunner.run(ISafeRunnable) line: 42 PartRenderingEngine.createGui(MUIElement) line: 716 PartRenderingEngine.subscribeChildrenHandler(Event) line: 305 GeneratedMethodAccessor8.invoke(Object, Object[]) line: not available DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 MethodRequestor.execute() line: 55 EventObjectSupplier$DIEventHandler.handleEvent(Event) line: 88 EventHandlerWrapper.handleEvent(Event, Permission) line: 201 EventHandlerTracker.dispatchEvent(EventHandlerWrapper, Permission, int, Event) line: 196 EventHandlerTracker.dispatchEvent(Object, Object, int, Object) line: 1 EventManager.dispatchEvent(Set<Entry<K,V>>, EventDispatcher<K,V,E>, int, E) line: 230 ListenerQueue<K,V,E>.dispatchEventSynchronous(int, E) line: 148 EventAdminImpl.dispatchEvent(Event, boolean) line: 135 EventAdminImpl.sendEvent(Event) line: 78 EventComponent.sendEvent(Event) line: 39 EventBroker.send(String, Object) line: 52 UIEventPublisher.notifyChanged(Notification) line: 60 TrimBarImpl(BasicNotifierImpl).eNotify(Notification) line: 374 ElementContainerImpl$1(EcoreEList<E>).dispatchNotification(Notification) line: 249 ElementContainerImpl$1(NotifyingListImpl<E>).addUnique(E) line: 294 ElementContainerImpl$1(AbstractEList<E>).add(E) line: 305 WorkbenchWindow.populateStandardTrim(MTrimBar) line: 1139 WorkbenchWindow.populateBottomTrimContributions() line: 1269 WorkbenchWindow.setup() line: 677 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 MethodRequestor.execute() line: 55 InjectorImpl.processAnnotated(Class<Annotation>, Object, Class<?>, PrimaryObjectSupplier, PrimaryObjectSupplier, ArrayList<Class<?>>) line: 1002 InjectorImpl.internalInject(Object, PrimaryObjectSupplier, PrimaryObjectSupplier) line: 136 InjectorImpl.inject(Object, PrimaryObjectSupplier) line: 92 ContextInjectionFactory.inject(Object, IEclipseContext) line: 74 Workbench.createWorkbenchWindow(IAdaptable, IPerspectiveDescriptor, MWindow, boolean) line: 1496 Workbench.getActiveWorkbenchWindow() line: 1470 WorkbenchSourceProvider.updateActiveShell(Map) line: 907 WorkbenchSourceProvider.getCurrentState() line: 115 WorkbenchSourceProvider.lambda$2(Event) line: 668 1181740538.handleEvent(Event) line: not available EventTable.sendEvent(Event) line: 86 Display.filterEvent(Event) line: 1660 Shell(Widget).sendEvent(Event) line: 1362 Shell(Widget).sendEvent(int, Event, boolean) line: 1389 Shell(Widget).sendEvent(int) line: 1368 Shell.gtk_focus_in_event(long, long) line: 1401 Shell(Widget).windowProc(long, long, long) line: 1979 Shell(Control).windowProc(long, long, long) line: 6252 Display.windowProc(long, long, long) line: 5841 OS._gtk_main_do_event(long) line: not available [native method] OS.gtk_main_do_event(long) line: 9209 Display.eventProc(long, long) line: 1335 OS._g_main_context_iteration(long, boolean) line: not available [native method] OS.g_main_context_iteration(long, boolean) line: 2133 Display.readAndDispatch() line: 4413 PartRenderingEngine$5.run() line: 1150 Realm.runWithDefault(Realm, Runnable) line: 336 PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 1039 E4Workbench.createAndRunUI(MApplicationElement) line: 153 Workbench.lambda$3(Display, WorkbenchAdvisor, int[]) line: 681 912790599.run() line: not available Realm.runWithDefault(Realm, Runnable) line: 336 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 595 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 148 IDEApplication.start(IApplicationContext) line: 152 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 134 EclipseAppLauncher.start(Object) line: 104 EclipseStarter.run(Object) line: 388 EclipseStarter.run(String[], Runnable) line: 243 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 Main.invokeFramework(String[], URL[]) line: 655 Main.basicRun(String[]) line: 591 Main.run(String[]) line: 1501 Main.main(String[]) line: 1474 The second and so on executions have stack: Thread [main] (Suspended (breakpoint at line 269 in StatusLine)) StatusLine.<init>(Composite, int) line: 269 StatusLineManager.createControl(Composite, int) line: 100 StatusLineManager.createControl(Composite) line: 86 StandardTrim.createStatusLine(Composite, MToolControl) line: 127 StandardTrim.createWidget(Composite, MToolControl) line: 45 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 MethodRequestor.execute() line: 55 InjectorImpl.processAnnotated(Class<Annotation>, Object, Class<?>, PrimaryObjectSupplier, PrimaryObjectSupplier, ArrayList<Class<?>>) line: 1002 InjectorImpl.internalInject(Object, PrimaryObjectSupplier, PrimaryObjectSupplier) line: 136 InjectorImpl.internalMake(Class<?>, PrimaryObjectSupplier, PrimaryObjectSupplier) line: 411 InjectorImpl.make(Class<T>, PrimaryObjectSupplier, PrimaryObjectSupplier) line: 344 ContextInjectionFactory.make(Class<T>, IEclipseContext, IEclipseContext) line: 214 ReflectionContributionFactory.createFromBundle(Bundle, IEclipseContext, IEclipseContext, URI) line: 108 ReflectionContributionFactory.doCreate(String, IEclipseContext, IEclipseContext) line: 74 ReflectionContributionFactory.create(String, IEclipseContext, IEclipseContext) line: 51 ToolControlRenderer.createWidget(MUIElement, Object) line: 126 PartRenderingEngine.createWidget(MUIElement, Object) line: 992 PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 661 PartRenderingEngine.safeCreateGui(MUIElement) line: 767 PartRenderingEngine.access$0(PartRenderingEngine, MUIElement) line: 738 PartRenderingEngine$2.run() line: 732 SafeRunner.run(ISafeRunnable) line: 42 PartRenderingEngine.createGui(MUIElement) line: 716 TrimBarRenderer(SWTPartRenderer).processContents(MElementContainer<MUIElement>) line: 69 TrimBarRenderer.processContents(MElementContainer<MUIElement>) line: 127 PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 675 PartRenderingEngine$1.run() line: 546 SafeRunner.run(ISafeRunnable) line: 42 PartRenderingEngine.createGui(MUIElement, Object, IEclipseContext) line: 530 WBWRenderer.processContents(MElementContainer<MUIElement>) line: 726 PartRenderingEngine.safeCreateGui(MUIElement, Object, IEclipseContext) line: 675 PartRenderingEngine.safeCreateGui(MUIElement) line: 767 PartRenderingEngine.access$0(PartRenderingEngine, MUIElement) line: 738 PartRenderingEngine$2.run() line: 732 SafeRunner.run(ISafeRunnable) line: 42 PartRenderingEngine.createGui(MUIElement) line: 716 PartRenderingEngine$5.run() line: 1076 Realm.runWithDefault(Realm, Runnable) line: 336 PartRenderingEngine.run(MApplicationElement, IEclipseContext) line: 1039 E4Workbench.createAndRunUI(MApplicationElement) line: 153 Workbench.lambda$3(Display, WorkbenchAdvisor, int[]) line: 681 1119371910.run() line: not available Realm.runWithDefault(Realm, Runnable) line: 336 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 595 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 148 IDEApplication.start(IApplicationContext) line: 152 EclipseAppHandle.run(Object) line: 196 EclipseAppLauncher.runApplication(Object) line: 134 EclipseAppLauncher.start(Object) line: 104 EclipseStarter.run(Object) line: 388 EclipseStarter.run(String[], Runnable) line: 243 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43 Method.invoke(Object, Object...) line: 498 Main.invokeFramework(String[], URL[]) line: 655 Main.basicRun(String[]) line: 591 Main.run(String[]) line: 1501 Main.main(String[]) line: 1474 The toolbar contribution is created with similar differences between first and latter executions.
Trying to specify the correct location with e.g. locationURI="toolbar:org.eclipse.ui.trim.status?after=org.eclipse.ui.ProgressBar" leads to no visible contribution at all, for the first start in a workspace.
Same as https://bugs.eclipse.org/bugs/show_bug.cgi?id=422651#c15.
I think the problem here can be avoided if the status line, the heap status and the progress bar are added as contributions to the bottom trim bar. That way, they will be available when product specific contributions are initialized. Product contributions can then define a location (e.g. after progress bar), which will work also on the first time. However I'm not sure how the following code translates to a contribution: private void populateStandardTrim(MTrimBar bottomTrim) { // StatusLine MToolControl slElement = (MToolControl) modelService.find( STATUS_LINE_ID, model); if (slElement == null) { slElement = modelService.createModelElement(MToolControl.class); slElement.setElementId(STATUS_LINE_ID); slElement.setContributionURI(TRIM_CONTRIBUTION_URI); bottomTrim.getChildren().add(slElement); } slElement.setToBeRendered(statusLineVisible); slElement.getTags().add(TrimBarLayout.SPACER); // Heap Status MToolControl hsElement = (MToolControl) modelService.find( "org.eclipse.ui.HeapStatus", model); //$NON-NLS-1$ if (hsElement == null) { hsElement = modelService.createModelElement(MToolControl.class); hsElement.setElementId("org.eclipse.ui.HeapStatus"); //$NON-NLS-1$ hsElement.setContributionURI(TRIM_CONTRIBUTION_URI); hsElement.getTags().add(IPresentationEngine.DRAGGABLE); bottomTrim.getChildren().add(hsElement); } hsElement.setToBeRendered(getShowHeapStatus()); // Progress Bar MToolControl pbElement = (MToolControl) modelService.find( "org.eclipse.ui.ProgressBar", model); //$NON-NLS-1$ if (pbElement == null) { pbElement = modelService.createModelElement(MToolControl.class); pbElement.setElementId("org.eclipse.ui.ProgressBar"); //$NON-NLS-1$ pbElement.getTags().add(IPresentationEngine.DRAGGABLE); pbElement.setContributionURI(TRIM_CONTRIBUTION_URI); bottomTrim.getChildren().add(pbElement); } pbElement.setToBeRendered(getWindowConfigurer().getShowProgressIndicator()); } I also don't know where the contribution should land. I tried org.eclipse.ui, it misses the current definition class (MToolControl). I tried in org.eclipse.ui.workbench, it misses org.eclipse.ui and so it cannot see the menu contribution extension point.
As a workaround for our product, we added our contribution in the early start-up of one of our plug-ins. The bottom trim bar contribution is added in the same manner as the status line, heap status and progress bar. I.e. ask the model service to add it programmatically.
I see the same problem with tips, see bug 540662 comment 8.
Probably something like bug 411821 must be done for contributions done via WorkbenchWindow.populateTopTrimContributions() / WorkbenchWindow.populateBottomTrimContributions() code. The code above is a collection of some weird hacks, one after each other and with bug fixes on top... Also see bug 355059 (comment on line 933: "render now after everything has been added so contributions can be inserted in the right place"), where after adding some controls a call to updateLayoutDataForContents() is needed. In the case of the bottom trim, this call seem to be triggered not immediately on creation but later on, which might explain the different order.
Created attachment 277455 [details] tip of the day in the wrong place 4.11 head. Tip of the day is also affected. On very first startup it appears in lower left corner (wrong), next time in lower right corner (OK).
(In reply to Andrey Loskutov from comment #10) > 4.11 head. Tip of the day is also affected. On very first startup it appears > in lower left corner (wrong), next time in lower right corner (OK). Wim, was this not reported yet with tips?
(In reply to Andrey Loskutov from comment #11) > (In reply to Andrey Loskutov from comment #10) > > 4.11 head. Tip of the day is also affected. On very first startup it appears > > in lower left corner (wrong), next time in lower right corner (OK). > > Wim, was this not reported yet with tips? I have seen it mentioned but I have no bug. I have not seen this myself but I don't think it is a Tips invoked problem. We just add the icon to the trim status bar with no implied intention to have it left or right [1]. I guess the classes to investigate are in JFace: ApplicationWindow, StatusLineManager, and StatusLine. [1] https://github.com/eclipse/eclipse.platform.ua/blob/d5787f4ec2efdaeca98933ffd7c0772af37a8620/org.eclipse.tips.ide/plugin.xml#L49
New Gerrit change created: https://git.eclipse.org/r/141722
I have done some investigation. This is the summary. The problem is only for new workspaces. Which are initialized from default e4 model from "/org.eclipse.platform/LegacyIDE.e4xmi". In a new workspace, the menu contributions from extension points are being created before the status bar controls (StatusBar, Heap Status, Progressbar). Because the workspace e4 model is not found. In an old workspace, the status bar controls are initializing from a saved e4 workspace model. Which was created when a new workspace shutdown. So, status bar icons are aligned correctly on the second start. Proposed fix https://git.eclipse.org/r/#/c/141722/ Note: locationURI="toolbar:org.eclipse.ui.trim.status?before=org.eclipse.ui.StatusLine" will work for left side contributions.
(In reply to Lakshminarayana from comment #14) > > Proposed fix https://git.eclipse.org/r/#/c/141722/ Looks good to me. You investigated the children of an "old" startup and inserted these in the e4.xmi template? > > Note: > locationURI="toolbar:org.eclipse.ui.trim.status?before=org.eclipse.ui. > StatusLine" will work for left side contributions. Good to know. Thanks. This should be documented somewhere.
New Gerrit change created: https://git.eclipse.org/r/141732
(In reply to Wim Jongman from comment #15) > Looks good to me. You investigated the children of an "old" startup and > inserted these in the e4.xmi template? > I was tried for some products like JEE,SDK, etc.. Not sure, if I missed something. Someone, who is familiar in this area should review the commit. Some additional information These methods will create the statusbar and other controls programmatically if not found in the default e4 model.So, I fixed it in default e4 model ("/org.eclipse.platform/LegacyIDE.e4xmi") org.eclipse.e4.ui.internal.workbench.ModelServiceImpl.getTrim(MTrimmedWindow, SideValue) org.eclipse.ui.internal.WorkbenchWindow.populateStandardTrim(MTrimBar) In a new workspace, the menu contributions from extension points are being created before the status bar controls (StatusBar, Heap Status, Progressbar) are created. So icons or menus are adding left side. In an old workspace, the status bar controls are initializing from a saved e4 workspace model. Which was created after the first workspace launch. See {$eclipse-workspace}\.metadata\.plugins\org.eclipse.e4.workbench\workbench.xmi I think it's possible to fix programmatically. I feel it's a simple fix.
Gerrit change https://git.eclipse.org/r/141732 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.git/commit/?id=b51bad0dd2987cdeaa11e00713a5f9f74288c3d5
Thanks Lakshminarayana! I will keep this open till we have official SDK build results. Changed layout could lead to some UI test fails for tests which aren't run on platform gerrit build.
(In reply to Andrey Loskutov from comment #19) > Thanks Lakshminarayana! I will keep this open till we have official SDK > build results. Changed layout could lead to some UI test fails for tests > which aren't run on platform gerrit build. Looks good. I don't see unexpected fails in SDK.
Verified in I20190512-1800. Lakshminarayana: many thanks. Sometimes a small simple solution is all what is needed, the only problem that it is not always obvious where it is :-).
(In reply to Andrey Loskutov from comment #21) > Verified in I20190512-1800. > Lakshminarayana: many thanks. Sometimes a small simple solution is all what > is needed, the only problem that it is not always obvious where it is :-). Thanks Andrey. But, see Bug 494789. We can apply a similar solution. I think we need to think about an alternative solution too. Someone who is familiar in this area should think which is the best solution. https://bugs.eclipse.org/bugs/show_bug.cgi?id=494789#c2 "We need to fix it here by reordering the toolbar contributions after a new one added. org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.fixZOrder(MUIElement) Line 428 to 440 "
While the change fixes the problem with the "Tips" contribution in the pure SDK, it does *not* fixes the problem in our custom application build on top of that SDK. Note #1: we don't contribute any extra e4xmi file, we just reuse the one from SDK. Note #2: "Tips" are still broken in our custom product, based on the same build as SDK where "Tips" are properly shown. => reopening.
(In reply to Andrey Loskutov from comment #23) > While the change fixes the problem with the "Tips" contribution in the pure > SDK, it does *not* fixes the problem in our custom application build on top > of that SDK. > > Note #1: we don't contribute any extra e4xmi file, we just reuse the one > from SDK. > Note #2: "Tips" are still broken in our custom product, based on the same > build as SDK where "Tips" are properly shown. > > => reopening. Can you explain a little bit more ?. I was tested on Eclipse JEE (org.eclipse.epp.package.jee.product). "Tips" contribution showing fine there.
(In reply to Andrey Loskutov from comment #23) > While the change fixes the problem with the "Tips" contribution in the pure > SDK, it does *not* fixes the problem in our custom application build on top > of that SDK. > > Note #1: we don't contribute any extra e4xmi file, we just reuse the one > from SDK. > Note #2: "Tips" are still broken in our custom product, based on the same > build as SDK where "Tips" are properly shown. > > => reopening. How do we fix your custom application? Did you clear your workspace or run with -clearPersistedState?
(In reply to Wim Jongman from comment #25) > (In reply to Andrey Loskutov from comment #23) > > While the change fixes the problem with the "Tips" contribution in the pure > > SDK, it does *not* fixes the problem in our custom application build on top > > of that SDK. > > > > Note #1: we don't contribute any extra e4xmi file, we just reuse the one > > from SDK. > > Note #2: "Tips" are still broken in our custom product, based on the same > > build as SDK where "Tips" are properly shown. > > > > => reopening. > > How do we fix your custom application? Did you clear your workspace or run > with -clearPersistedState? I'm always talking about fresh new workspace here, created from scratch. The attached example works fine in SDK, but not in our application, but I've found the root cause. Looks like during 3.x -> 4.x transition we forgot to add applicationXMI to the product. OMFG. Adding this "fixed" the problem in our product too: <property name="applicationXMI" value="org.eclipse.platform/LegacyIDE.e4xmi" /> But I'm wondering what was used *by default* then??? I see no differences so far. But this is unrelated to the current bug, it is our internal issue, so sorry for the noise, the bug is really fixed.
(In reply to Andrey Loskutov from comment #26) > But I'm wondering what was used *by default* then??? I see no differences so > far. OMG. OMG. We have *two* LegacyIDE.e4xmi files, that diverged slightly... /org.eclipse.platform/LegacyIDE.e4xmi /org.eclipse.ui.workbench/LegacyIDE.e4xmi And guess what... The one from org.eclipse.ui.workbench is used by default if the product does not specify org.eclipse.e4.ui.workbench.IWorkbench.XMI_URI_ARG, see org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) which sets the default and org.eclipse.e4.ui.internal.workbench.swt.E4Application.getArgValue(String, IApplicationContext, boolean) which reads the default if not specified by the product. Looks like the one that is used by default was added via bug 317912 exactly for the case that someone migrates 3.x to 4.x and does not have that magic e4xmi crap defined. I think we should also update the default => will push the patch in a moment.
New Gerrit change created: https://git.eclipse.org/r/142519
(In reply to Andrey Loskutov from comment #27) > (In reply to Andrey Loskutov from comment #26) > > But I'm wondering what was used *by default* then??? I see no differences so > > far. > > OMG. OMG. We have *two* LegacyIDE.e4xmi files, that diverged slightly... LOL!! Nice catch.
Gerrit change https://git.eclipse.org/r/142519 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=f1bb722e919874f28e8c4ff6488e216061b3ec0d
(In reply to Eclipse Genie from comment #30) > Gerrit change https://git.eclipse.org/r/142519 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/ > ?id=f1bb722e919874f28e8c4ff6488e216061b3ec0d In master now, both files are updated.
Verified with I20190521-1800
