Community
Participate
Working Groups
Created attachment 218995 [details] Project to reproduce the bug Calling a close view followed by an open view of the same view the view gets correctly removed (hidden) but not anymore opened. Might be a threading issue. To reproduce with: [code] IViewPart view = getSite().getPage().findView(SecondView.ID); if (view != null) { getSite().getPage().hideView(view); } try { getSite().getPage().showView(SecondView.ID); } catch (PartInitException e1) { e1.printStackTrace(); } [/code] Or with the attached project. -andreas
Andreas, thanks for the project... I've tagged this for a look in 4.3 but downgraded the severity to normal given that this pattern is quite unlikely to be common...if you have a use-case for this being common just post it here...
Eric, thanks for taking a look at the bug. And yes there is a common use case for such a behavior (see also http://www.eclipse.org/forums/index.php/t/367595/). Eclipse Scout applications are fully model based as E4 applications. A view is nothing else than a model component containing a view id property. To get there with Eclipse 3.x versions we had to predefine a set of view extensions (plugins.xml) and map those to the model ids. To have an example I attached a screenshot of such an application. The right part 'PersonForm'(model) presented in the 'DetailView'(UI) changes on any selection in the tree on the left hand side. Model side there is first detached the previous form and attached the new form afterwards. The UI layer listening to these changes does not know about a immediately reuse of the UI view. If you can give me any start point I can try to provide a patch for this bug. -andreas
Created attachment 219073 [details] screenshot of sample Scout app
Created attachment 232090 [details] Extended sample application to reproduce the bug
This bug is quite important for us since it effects our Scout project as described in bug 406764 or in the forum http://www.eclipse.org/forums/index.php/t/449568/. We have only found an ugly workaround so far by scheduling the hideView() method call asynchronously for E4. I extended the sample SWT application by Andreas to show that this is definitely an E4 bug. I added two target files, one containing the Eclipse Juno 3.8 and the other containing the Juno 4.2 platform. If you start the application with the eclipse-3.8 target, the bug doesn't occur. However, if using the eclipse-4.2 target, the described problem is reproducible. I also extended the sample application to allow multiple instances of the SecondView. There's now a new button to open another instance of the SecondView. Closing and re-opening the first instance of the SecondView works perfectly in this case. I attached a PartListener that prints the events to the system output. If you initially click on the button "Open View" that starts the SecondView and then click on the button "Close and Open View", the SecondView disappears and isn't re-opened. In the event log the following output can be seen after pressing the "Close and Open View" button: Second View hidden Second View closed Second View opened Second View visible Second View brought to top First View deactivated Second View activated Second View hidden Second View closed Actually the SecondView is re-opened but somehow the last two events are responsible for closing the view again. However, if another instance of the SecondView has been opened before, the last two events are not fired. I suspect that there's a multi-threading issue so that these events are fired in E4 because there aren't any references to the SecondView at the time the view gets closed on purpose.
Thank you Paul to upgrade the severity. This bug is a huge issue for Eclipse Scout. We look forward to get it solved till V4.3.1. -andreas
OK, I have a fix posted to Gerrit: https://git.eclipse.org/r/13651 The problem was that there was indeed an asynchExec in our CleanupAddon that was responsible for tearing down empty stacks. It was *not* re-checking whether the stack was still empty before tearing it down, causing the issue (Closing the only instance of SecondView meant the stack went empty and the asynch was triggered to run later...but...before it ran the new SecondView was opened so the stack was no longer empty). Thanks for picking this up, we don't see it under normal running where closing a view is usually a discreet operation.
Thank you Eric for pushing patch so quickly to Gerrit. The patch seems reasonable to me and confirms our assumption about a multi-threading issue.
Ken, thanks for the verification, this patch will certainly make it into 4.3.1.
This code has already been committed to the R4_3_maintenance stream (and master)...
Eric, the fix does solve our SWT problem described in bug 387625. Thanks a lot!
Verified in the build: M20130828-0800
