Community
Participate
Working Groups
Created attachment 207921 [details] stacktrace (error in PartRenderingEngine) I get the attached exception when running the EMF Facet SWTBot tests on Eclipse 4.2M3 on Hudson.
Created attachment 207922 [details] stacktrace (error in CleanupAddon) I also get a similar error from a different part of the code (CleanupAddon) : see attached stacktrace.
Created attachment 207923 [details] screenshot of the workbench during a test Maybe this is related, so I'm attaching a screenshot of the workbench during a test, which shows that the editor area is strangely positioned.
(In reply to comment #0) > Created attachment 207921 [details] > stacktrace (error in PartRenderingEngine) > > I get the attached exception when running the EMF Facet SWTBot tests on Eclipse > 4.2M3 on Hudson. So I'm guessing this doesn't happen when running the tests locally?
No, I haven't seen it yet when running the tests locally (on Windows 7 x64).
*** Bug 404415 has been marked as a duplicate of this bug. ***
(In reply to comment #3) > So I'm guessing this doesn't happen when running the tests locally? It happens locally here (Linux), see also bug 404415 (possible duplicate). How to reproduce: 1. Install SWTBot 2. Set up for EGit development: https://wiki.eclipse.org/EGit/Contributor_Guide 3. Open ShowInTest, Run As > SWTBot Test I debugged a bit, and the widget that is disposed is the "Limbo" shell, as created in PartRenderingEngine#getLimboShell. It is closed (and thus disposed) by some SWT support code in EGit which closes all shells except the active workbench window shell. The question is, should we somehow detect the limbo shell and not close it, or should getLimboShell create a new one when the one it had was disposed?
I'd say to detect it, it's most distinguishing factor is that it's SWT 'visible' state is false (i.e. it doesn't show up in the presentation. Actually, the 'limbo' shell is used to reparent UI Model elements whose own 'visible' flag is false; allowing them to remain 'real' SWT widgets but hiding them from the user's current presentation.
(In reply to Eric Moffatt from comment #7) > I'd say to detect it, it's most distinguishing factor is that it's SWT > 'visible' state is false (i.e. it doesn't show up in the presentation. Done in EGit: https://git.eclipse.org/c/egit/egit.git/commit/?id=0aa004df4f12634f2f96388a5a0e062575f1e07a Whether getLimboShell should recreate the limbo shell if it's disposed is for the platform to decide.
I am in the same scenario: CleanupAddon tries to reparent a control to the "limbo" shell which is disposed. I am also running a local SWTBot test (4.3 with compatibility layer). Is there a workaround for this? Is it safe to replace the "limbo" shell with a new functioning "limbo" shell before a test is executed? The most interesting question would still be: why is the "limbo" shell disposed at all?
This could potentially be called by a call to SWTWorkbenchBot.closeAllShells() somewhere in code. I tested that call from SWTBot 2.3.0 and found it calls .close() on the limbo shell.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
