Community
Participate
Working Groups
I've noticed miscellaneous bugs with the view management. Here are some of them (ones I can reproduce). Here's the first I just noticed while trying to reproduce other ones : The default container of the Package / Navigator / Project Explorer views, when minimized and while dragging it around, can be lost. The left mouse button is not released but the container does not appear anywhere. It is not docked into a default location or something (I checked and rechecked). And I can't make it reappear by trying to open that view with the Window > Show view menu. I must reinitialize the perspective to get it back. It seems it does not occur with the other minimized view containers, though the cursor can lost the container while dragging it and then it is automatically relocated at a default (or last) position but remains green as still being moved. More over, when I try to place the minimized Package view container at the left bottom corner, it doesn't want to keep that location after being maximized and minimized again ! Though, once placed at the left bottom corner, after a Eclipse restart, it remains at that location until I maximized&minimized it. The other view containers seem to be less sensible to that phenomena. And to finish on those view containers issues, on an other Kepler installation, I have troubles with the Package and Navigator views because they are duplicated, one or more times into the container, after being minimized&maximized. Very difficult to close the duplicates, and it seems impossible to fix... That bug is more difficult to reproduce, I'll try to provoke it again. Hope it's clear enough. Thank you. -- Configuration Details -- Product: Eclipse 2.0.0.20130613-0530 (org.eclipse.epp.package.jee.product) Installed Features: org.eclipse.platform 4.3.0.v20130605-2000
Created attachment 233646 [details] Package view container desappeared
So the problem happens when you minimize the stack with the explorer(s) in it and then drag it to other locations within the trim correct ? I just tried this in my own eclipse session and I'm seeing the following stack: org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:4397) at org.eclipse.swt.SWT.error(SWT.java:4312) at org.eclipse.swt.SWT.error(SWT.java:4283) at org.eclipse.swt.widgets.Widget.error(Widget.java:472) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:344) at org.eclipse.swt.widgets.Control.getParent(Control.java:1501) at org.eclipse.e4.ui.workbench.renderers.swt.TrimBarLayout.ctrlFromPoint(TrimBarLayout.java:314) at org.eclipse.e4.ui.workbench.addons.dndaddon.TrimDropAgent.getInsertionElement(TrimDropAgent.java:86) at org.eclipse.e4.ui.workbench.addons.dndaddon.TrimDropAgent.track(TrimDropAgent.java:165) Do you see anything like this in your error log ?
(In reply to comment #2) > So the problem happens when you minimize the stack with the explorer(s) in > it and then drag it to other locations within the trim correct ? Yes, the explorer or other views. > I just tried this in my own eclipse session and I'm seeing the following > stack: > .... > Do you see anything like this in your error log ? Yes and I also have that one : java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList.java:440) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUnique(NotifyingListImpl.java:387) at org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:345) at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:339) at org.eclipse.e4.ui.workbench.addons.dndaddon.TrimDropAgent.dock(TrimDropAgent.java:201) at org.eclipse.e4.ui.workbench.addons.dndaddon.TrimDropAgent.track(TrimDropAgent.java:185) at org.eclipse.e4.ui.workbench.addons.dndaddon.DragAgent.track(DragAgent.java:112) at org.eclipse.e4.ui.workbench.addons.dndaddon.IBFDragAgent.track(IBFDragAgent.java:114) at org.eclipse.e4.ui.workbench.addons.dndaddon.DnDManager$4.run(DnDManager.java:186) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:180) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4688)
I can't seem to repro the dragging / disappearing trim stack using my current (latest) build. I've recently observed that switching perspectives *can* result in views being shown (wrongly) in the perspective being switched *to*, perhaps this is the cause of the duplicates ??
Laurent, can you still reproduce the loss of the stack (your first issue) ? If so please try to provide an updated description of how you managed it. It'll be impossible to fix if I can't get it to happen. I do know that this was possible and I don't remember anything explicit that I've done that might have fixed it so maybe I'm just getting (un)lucky...;-).
Please tell me precise version to test with.
If you can access the developer builds then try the latest I-build; I20130820-0800
(In reply to comment #7) > If you can access the developer builds then try the latest I-build; > I20130820-0800 This is the build that I started using in response to Bug 409652 Comment #1, and it was only after using this build that I observed this phenomenon. In my case it was the minimized bottom row of the debug perspective that was invisible. (Possibly caused by a mal-sizing of the perspective tool bar as a result of starting with Papyrus not installed nad consequently the vertical toolar displaying as a double column to show the "Payrus" text horizontally where it would normally have shown the icon.)
(In reply to comment #7) > If you can access the developer builds then try the latest I-build; > I20130820-0800 Why targeting E4.4 ? What about E4.3 SR1 ? According to me, E4.4 should be delayed because of too much E4.x regressions. I consider E4.2 and E4.3 as beta versions. I'm asking myself if I wouldn't go back to E3.7... This is not the question of the current bug, because it's not the most annoying one but for me it just reveals some core instabilities. Well, E4.4 I20130820-0800 seems to be a little bit more stable against that bug because I can't reproduce the lost of the minimized stack. Anyway, it can be difficult sometimes to move it at specific location once it started to get green and keeping that color even with mouse button released. And then I can see a grey square lost on the screen (the background of the stack area), at the location where the stack has been disconnected from the mouse dragging operation. If you want to reproduce it, I think you have to insist, switching perspectives, moving around minimized stacks, getting the them outside of the Eclipse window... Maybe, behavior can be different with a full Eclipse JEE package, I don't know. I just tried the basic E4.4 you pointed me, so the comparison with E4.3 maybe not complete. Here is a new stack trace : !ENTRY org.eclipse.ui 4 0 2013-08-25 13:53:51.828 !MESSAGE Unhandled event loop exception !STACK 0 org.eclipse.swt.SWTException: Widget is disposed at org.eclipse.swt.SWT.error(SWT.java:4397) at org.eclipse.swt.SWT.error(SWT.java:4312) at org.eclipse.swt.SWT.error(SWT.java:4283) at org.eclipse.swt.widgets.Widget.error(Widget.java:472) at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:344) at org.eclipse.swt.widgets.Control.getParent(Control.java:1501) at org.eclipse.e4.ui.workbench.renderers.swt.TrimBarLayout.ctrlFromPoint(TrimBarLayout.java:319) at org.eclipse.e4.ui.workbench.addons.dndaddon.TrimDropAgent.getInsertionElement(TrimDropAgent.java:86) at org.eclipse.e4.ui.workbench.addons.dndaddon.TrimDropAgent.track(TrimDropAgent.java:165) at org.eclipse.e4.ui.workbench.addons.dndaddon.TrimDropAgent.dragEnter(TrimDropAgent.java:135) at org.eclipse.e4.ui.workbench.addons.dndaddon.DragAgent.track(DragAgent.java:122) at org.eclipse.e4.ui.workbench.addons.dndaddon.IBFDragAgent.track(IBFDragAgent.java:114) at org.eclipse.e4.ui.workbench.addons.dndaddon.DnDManager$4.run(DnDManager.java:186) at org.eclipse.swt.widgets.Synchronizer.syncExec(Synchronizer.java:180) at org.eclipse.ui.internal.UISynchronizer.syncExec(UISynchronizer.java:150) at org.eclipse.swt.widgets.Display.syncExec(Display.java:4688) at org.eclipse.e4.ui.workbench.addons.dndaddon.DnDManager.track(DnDManager.java:183) at org.eclipse.e4.ui.workbench.addons.dndaddon.DnDManager.access$1(DnDManager.java:182) at org.eclipse.e4.ui.workbench.addons.dndaddon.DnDManager$6.handleEvent(DnDManager.java:218) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1081) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1066) at org.eclipse.swt.widgets.Tracker.wmMouse(Tracker.java:1179) at org.eclipse.swt.widgets.Tracker.open(Tracker.java:587) at org.eclipse.e4.ui.workbench.addons.dndaddon.DnDManager.startDrag(DnDManager.java:230) at org.eclipse.e4.ui.workbench.addons.dndaddon.DnDManager$1.dragDetected(DnDManager.java:88) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:127) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4170) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997) at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:138) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:610) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591) at org.eclipse.equinox.launcher.Main.run(Main.java:1450) I guess it may be complex to fix, so good luck.
Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=bb702b0f3d3b5bd21a4c8f76140cddebf76369f2 Adds some safety checks... Laurent, *all* defects are first fixed in 'master' then some are back ported. Since this is a safe fix I'll open a 4.3.2 version. Ordinarily I wouldn't do this because we have no definitive steps to reproduce the problem nor has it been reported from other sources but since the effect is simply to safe up the code it can't hurt...
Ok... I tried again to determine steps to reproduce that bug, without success for the moment. It occurs quite easily in my environment, I'll try on another computer. I've also noticed a new strange behavior while trying to reopen minimized stacks (in Debug perspective with E4.4), they were just disappearing. Funny... I didn't tried to reproduce it.
Verified in the build: I20130916-2330
