After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 591373 - In Eclipse, buttons associated with a detached view vanish when it is moved
In Eclipse, buttons associated with a detached view vanish when it is moved
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
2.17.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
csw
Depends on:
Blocks:
 
 
Reported: 2009-08-10 20:25 UTC by Max Bowsher
Modified: 2009-09-03 12:42 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Attachments
Screenshot showing the problem. (4.75 KB, image/png)
2009-08-17 16:39 UTC, Max Bowsher
Details
Screenshot showing what is supposed to appear (6.32 KB, image/png)
2009-08-17 16:40 UTC, Max Bowsher
Details

Description Max Bowsher 2009-08-10 20:25:52 UTC
Please describe the problem:
(An Eclipse-specific bug, sorry. I've not found anything simpler that reproduces it.)

In Eclipse, views such as the Console or Search view have a toolbar of buttons that appears to the right of the tab bearing the name of the view. Starting in gtk+ 2.17.3 (2.17.2 is not affected), this toolbar of buttons disappears when the view is dragged between windows, and will then not reappear until Eclipse is restarted.

Steps to reproduce:
1. Start Eclipse, and ensure that the Console and/or Search views are visible and docked within the main window. If they were not already, quit and restart Eclipse now.
2. Observe that a toolbar of buttons relating to the view is present to the right of its tab.
3. Drag the view so that it becomes detached from the main window.
4. Observe that the toolbar has vanished.


Actual results:
(see above)

Expected results:
The toolbar should not disappear

Does this happen every time?
Yes.

Other information:
Ubuntu Karmic (development release), up to date.
gtk+ 2.17.6. Rolling back to previous versions isolates the introduction of the problem to between 2.17.2 and 2.17.3. However, hacking the source of gdk_window_new to create all windows as native, which alleviates several other bugs, does *not* alleviate this one.
Comment 1 Matthias Clasen 2009-08-17 13:13:07 UTC
Can you please retry with 2.17.7 (or even better with 2.17.8, due out later this week). Several csw regressions have been fixed since 2.17.6.
Comment 2 Max Bowsher 2009-08-17 14:06:38 UTC
Still a problem with 2.17.7. I'll attempt to build git HEAD and try it, though I've never built gtk+ before.
Comment 3 Alexander Larsson 2009-08-17 15:54:09 UTC
"which alleviates several other bugs"

Are these bugs filed in bugzilla? If so, could you tag them with "csw" in the whiteboard?
Comment 4 Alexander Larsson 2009-08-17 15:57:21 UTC
Also, i'm not quite sure what you mean by the toolbar. Can you attach a screenshot of what you mean?
Comment 5 Max Bowsher 2009-08-17 16:33:16 UTC
(In reply to comment #3)
> "which alleviates several other bugs"
> 
> Are these bugs filed in bugzilla? If so, could you tag them with "csw" in the
> whiteboard?

http://bugzilla.gnome.org/show_bug.cgi?id=589963
 - Not tagged, Bugzilla seems to be denying me the right to edit the whiteboard.

http://bugzilla.gnome.org/show_bug.cgi?id=588437
 - Was already tagged, and RESOLVED FIXED.
Comment 6 Max Bowsher 2009-08-17 16:39:59 UTC
Created attachment 140978 [details]
Screenshot showing the problem.
Comment 7 Max Bowsher 2009-08-17 16:40:23 UTC
Created attachment 140979 [details]
Screenshot showing what is supposed to appear
Comment 8 Max Bowsher 2009-08-17 16:43:18 UTC
(In reply to comment #4)
> Also, i'm not quite sure what you mean by the toolbar. Can you attach a
> screenshot of what you mean?

I've attached two screenshots, one showing the view appearing correctly immediately after Eclipse startup, and one showing the same view with some UI elements missing after docking it and undocking it.
Comment 9 Max Bowsher 2009-08-17 21:14:27 UTC
I confirm still an issue in git 2.17.7-36-gc930f3a.
Comment 10 Alexander Larsson 2009-08-21 14:03:38 UTC
I found this lovely piece of SWT in Control.setZOrder()
http://demo.spars.info/j/show.cgi?compo_id=145868&ref=1#METHOD3316

It calls XReconfigureWMWindow direcly, thus making gdks knowledge of the stacking order incorrect wrt what is on the Xserver and what SWT wants/needs. This happens even pre-csw, but with csw it is more problematic as this information is used to calculate window clip regions, leading to this bug.
Comment 11 Alexander Larsson 2009-08-21 19:06:30 UTC
Bug filed against swt:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=287307
Comment 12 Alexander Larsson 2009-08-24 13:25:58 UTC
I added a workaround mode that uses only native windows that can be enabled with GDK_NATIVE_WINDOWS. If this is enable then this bug disappears. I don't see any other way to reliably fix this, but it would be nice to fix future SWT releases to not need this.
Comment 13 Alexander Larsson 2009-09-03 12:42:54 UTC
I added gdk_window_restack which can be used to fix this. I verified this by writing a eclipse patch to use it and it fixed the issue. The patch is attached to the eclipse bug report. I consider this closed from the gtk+ side.