Community
Participate
Working Groups
I don't know if the problem comes from SWT or the synchronize view itself. See the attached screenshot. I got a "floating" toolbar. The toolbar was no longer attached to the right view. As soon as I resized the window, it was back to normal.
Created attachment 69199 [details] Screenshot
I know that Paul and/or Eric have investigated floating toolbar issues in the past.
Upon upgrade to 3.5, OSEE (www.eclipse.org/osee) applications started showing floating toolbars from different views (see screenshot). The toolbar is actually from the second view in the stack. Only work-around is resetting the perspective. I have tried to debug this extensively and can't see anything the views are doing wrong. The floating toolbar doesn't come from the same view everytime. It all depends on which perspective is opened and which views are in the stack. If kill process and restart, it comes back every time. Resizing view manually or by double-click does nothing. Only reset perspective and shutting down normally will cure the problem for a while. See attachment
Created attachment 149310 [details] Floating toolbar from view in stack
Don, a few starter questions...;-) Did you get this when switching away from the 'second' view to the one in the image? Had that TB been visible during this eclipse session? Is there some repeatable set of steps I might use to reproduce this? Do you know if the application is doing anything 'funky' such as modifying which views are active...during a perspective switch or other operation? While we have had quite a number of issues with 'floating' TB's in the past but (for us) most of them have gone away in 3.5, I'm just trying to figure out what might be different in your environment.
>Did you get this when switching away from the 'second' view to the one in the >image? Had that TB been visible during this eclipse session? We started to encounter the problem when we migrated to 3.5 about a month ago. Happens on startup (both released application and runtime) and does not get cleaned up by expanding view manually (dragging right edge) or full-screen-expanding by double-clicking view tab. It does get cleaned up by selecting the view that "owns" the toolbar or by resetting the perspective. Seems to go away for a while and then something causes it to come back. >Is there some repeatable set of steps I might use to reproduce this? I have not found a reliable way of repeating, however once it starts happening in a runtime, I can make it happen every time by killing the debug session without shutting down normally. I have re-worked all the views in that quadrant (3-4) and even gutted the offending view until there was nothing but one contribution in the toolbar and no change. >Do you know if the application is doing anything 'funky' such as modifying >which views are active...during a perspective switch or other operation? These are standard views just loading the first time. And what finally made me assume it was an eclipse bug is we started seeing it in different perspectives with different views contributing the floating toolbar. They are our perspectives, but I couldn't find anything in the perspective definition that would cause it. >While we have had quite a number of issues with 'floating' TB's in the past but >(for us) most of them have gone away in 3.5, I'm just trying to figure out what >might be different in your environment. Is there anything that will refresh a toolbar after all views created besides getViewSite().getActionBars().updateActionBars(); ? It's weird that a reset perspective causes everything to re-calculate and draw correctly.
Created attachment 155473 [details] The buggy version of the ATS perspective
Created attachment 155474 [details] The new ATS perspective that works around the floating toolbar bug
I was able to determine a procedure to reliably reproduce this bug in OSEE's ATS perspective: 1) Reset the ATS perspective 2) Open the Artifact Explorer view 3) Double-click a folder to open it in the Artifact Editor 4) Open the ATS Navigator 5) Click the artifact editor pane, so that it is active 6) Close and restart OSEE I found it interesting that step (5) is crucial. Any artifact editors that are open upon shutdown will not be there after OSEE is restarted, and if (for instance) the ATS Navigator is the active view (instead of the artifact editor) the floating toolbar bug will not appear. The workaround was to move the views into different folders, and limit the number of views in any one folder. Nonetheless, I've found that I can still occasionally reproduce the bug if too many views accumulate in the bottom folder. In such a case, the toolbar of the first toolbar-bearing view in the bottom folder will float in the usual location (which is shown in Don's screen shot).
Created attachment 155777 [details] Floating toolbar in Eclipse's Debug perspective I just accidentally reproduced this bug in the Debug perspective. Here, the floating toolbar belongs to the History view (note the high density of tabs in that folder). When I last shut down Eclipse, the active view was an OSEE Artifact Editor. As I mentioned in a previous comment, these editors are not restored after restarts.
Ryan, you shut down with the Artifact Editor active but it isn't restored on a subsequent restart, correct? Thanks for this, it may give me a way to reproduce (and, ultimately, track down) this defect. I can set this scenario up fairly easily using Compare editors I think.
(In reply to comment #11) > Ryan, you shut down with the Artifact Editor active but it isn't restored on a > subsequent restart, correct? That's correct.
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. If you have further information on the current state of the bug, please add it. 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.
