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 581145 - Wrong positioning for fullscreen gedit toolbar animation
Wrong positioning for fullscreen gedit toolbar animation
Status: RESOLVED DUPLICATE of bug 582639
Product: mutter
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2009-05-03 00:02 UTC by Sander Dijkhuis
Modified: 2009-06-12 20:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sander Dijkhuis 2009-05-03 00:02:43 UTC
When running gedit in fullscreen mode (View > Fullscreen) within GNOME Shell, the toolbar is positioned wrong. It also seems to try to run from the mouse cursor when approached by it. After some dodges, it finally moves to the top of the screen where it hides above the text. From there it doesn't come back anymore.

(It's actually quite fun. I haven't managed to get the toolbar move to the bottom of the screen yet.)

The expected behavior is visible in Metacity, where the toolbar hides by default and is shown when the mouse cursor is at the top of the screen.
Comment 1 Owen Taylor 2009-06-12 18:58:11 UTC
Relevant bit dug up from my IRC logs:

<owen>  I'm not really sure exactly why it is breaking, but gtk_window_get_position() queries the window manager for where the window's frame is - so it's asynchronous - the code seems to be assuming it's just a simple getter for gtk_window_move()
<owen>  Oh, I know the problem
<owen>  I bet the problem is that mutter is setting _NET_FRAME_EXTENTS on override-redirect windows
<owen>  Without that, the code in gedit sort of coincidentally works, though it's still crackrock, but once you set _NET_FRAME_EXTENTS, the crackrock nature really reveals itself
<owen>  So, there's actually a GDK bug here, a Mutter bug, and a gedit bug
<sanderd>       that's probably not something I could handle yet :-)
<owen>  sanderd: if you can just file a bug report against mutter descriing the behavior, I can follow up there with my (so far unsubstantiated) theory
<sanderd>       sure
<owen>  (arguably if the GDK bug was fixed, then the gedit code would be OK. The fix to GDK is that if you call gdk_window_get_frame_extents() on a override-rediret window it should just use the locally stored position/size of the window)
<owen>  (so then calling gtk_window_position() on an override-redircet window would reliably give you the position you set with gtk_window_move())
<sanderd>       owen: do you still want this filed as a mutter bug then? the only thing it's doing wrong is setting _NET_FRAME_EXTENTS here?
<owen>  sanderd: Oh, there's definitely a mutter bug
<owen>  sanderd: and a GDK potential imrpovement. The question is whether there is a gedit bug as well - maybe not.
Comment 2 Owen Taylor 2009-06-12 19:52:53 UTC
my guess was completely off-base. The problem is simply that Mutter is positioning override-redirect windows!

meta_window_new_with_attrs() calls meta_window_move_resize_internal().
Comment 3 Owen Taylor 2009-06-12 19:55:04 UTC

*** This bug has been marked as a duplicate of 582639 ***
Comment 4 Owen Taylor 2009-06-12 20:04:42 UTC
I also filed bug 581145 since GTK+ *should* also be doing locally short-circuiting frame extents for override-redirect windows.