Firefox 60 / Thunderbird 52 weird positioning #2279
Comments
|
With "menubar", do you mean the bar at the top of the screen in the default config?
Uhm, what? |
|
Yes, i mean the bar at the top. And yes, when i open firefox 60 an switch to a different tag then the firefox window is still in the forground. xprop: |
|
Hm... nothing out of the ordinary in there. According to that output, firefox should only be on the fourth tag ( |
|
I just tried with the default rc.lua and have a similar behaviour. Output of your command: (paste to terminal and start firefox) Edit: i just recorded whats happening. Notice how i switch tags after i open firefox. |
|
Sorry, this is not related to the firefox version. I just downgraded to 59 and still have the issue so it will be something else. |
|
Hm... What? All I can say: Since Firefox also does not have an entry in the tasklist, even awesome thinks it is not visible. But clearly you can still interact with the window, so "it's there". So, what is your |
|
Yes, it happens with the default config - that's the active config In the video. |
|
I found the cause, the issue is because of GTK3 update. i3 currently has similar problems, see this thread for more info |
|
I am author of gtk3-mushrooms, gtk3 patched for classic desktops on Arch Linux. In current stable gtk3 newly created windows are filled by black color. In next gtk3 release newly created windows will be initially transparent — this causes bugs in Awesome and i3wm (i3wm bug here: i3/i3#3297 ). |
|
I am able to reproduce bug with any gtk3 app (when gtk3 is from gtk-3-22 branch). When gtk3 app is started it's not managed by awesome and goes to left-top corner. I will prepare video. |
|
With current stable gtk3: With gtk3 compiled with GNOME/gtk@2ce63a8: |
|
So, Gtk3 does not want the X11 server to fill the window with its background color. And instead of setting the background color to Plus, I should really make it a habit to ask "anything on awesome's stderr?"... @cars10 Running awesome with the |
|
@psychon Can you create issue on GTK3's bug tracker on gitlab.gnome.org? |
|
@TomaszGasior What exactly should I tell them? "I do not know why you are using Right now I wonder why only i3 and awesome seem to be affected, but I have a hard time coming up with WMs that try to make transparency in their decorations work... Perhaps I should just make all awesome users suffer by setting a black background pixel on a window that is used to contain Gtk windows, just so that they see that Edit: Sigh. Gdk needs |
|
If you think GDK behaves improperly maybe you can ask GTK authors about it on gtk-devel mailing list. It's here: https://mail.gnome.org/mailman/listinfo/gtk-devel-list |
|
Can someone who can reproduce this test the following patch?
What this does: Every client window with a different depth than the frame window that awesome would create for the titlebars (by default: basically every window except those wanting to use transparency; when using
diff --git a/objects/client.c b/objects/client.c
index c7a0c8e82..0e63da6cb 100644
--- a/objects/client.c
+++ b/objects/client.c
@@ -1270,9 +1270,19 @@ client_geometry_refresh(void)
xcb_configure_window(globalconf.connection, c->frame_window,
XCB_CONFIG_WINDOW_X | XCB_CONFIG_WINDOW_Y | XCB_CONFIG_WINDOW_WIDTH | XCB_CONFIG_WINDOW_HEIGHT,
(uint32_t[]) { geometry.x, geometry.y, geometry.width, geometry.height });
- xcb_configure_window(globalconf.connection, c->window,
- XCB_CONFIG_WINDOW_X | XCB_CONFIG_WINDOW_Y | XCB_CONFIG_WINDOW_WIDTH | XCB_CONFIG_WINDOW_HEIGHT,
- (uint32_t[]) { real_geometry.x, real_geometry.y, real_geometry.width, real_geometry.height });
+ if (c->container_window != XCB_NONE)
+ {
+ xcb_configure_window(globalconf.connection, c->container_window,
+ XCB_CONFIG_WINDOW_X | XCB_CONFIG_WINDOW_Y | XCB_CONFIG_WINDOW_WIDTH | XCB_CONFIG_WINDOW_HEIGHT,
+ (uint32_t[]) { real_geometry.x, real_geometry.y, real_geometry.width, real_geometry.height });
+ xcb_configure_window(globalconf.connection, c->window,
+ XCB_CONFIG_WINDOW_X | XCB_CONFIG_WINDOW_Y | XCB_CONFIG_WINDOW_WIDTH | XCB_CONFIG_WINDOW_HEIGHT,
+ (uint32_t[]) { 0, 0, real_geometry.width, real_geometry.height });
+ } else {
+ xcb_configure_window(globalconf.connection, c->window,
+ XCB_CONFIG_WINDOW_X | XCB_CONFIG_WINDOW_Y | XCB_CONFIG_WINDOW_WIDTH | XCB_CONFIG_WINDOW_HEIGHT,
+ (uint32_t[]) { real_geometry.x, real_geometry.y, real_geometry.width, real_geometry.height });
+ }
c->x11_frame_geometry = geometry;
c->x11_client_geometry = real_geometry;
@@ -1371,6 +1381,26 @@ client_update_properties(lua_State *L, int cidx, client_t *c)
window_set_opacity(L, cidx, xwindow_get_opacity_from_cookie(opacity));
}
+static xcb_visualid_t
+pick_visual_for_depth (uint8_t depth)
+{
+ xcb_depth_iterator_t depth_iter = xcb_screen_allowed_depths_iterator(globalconf.screen);
+
+ if (depth == globalconf.default_depth)
+ return globalconf.visual->visual_id;
+ if (depth == globalconf.screen->root_depth)
+ return globalconf.screen->root_visual;
+
+ /* Just pick the first visual of that depth */
+ for(; depth_iter.rem; xcb_depth_next (&depth_iter))
+ if (depth_iter.data->depth == depth)
+ for(xcb_visualtype_iterator_t visual_iter = xcb_depth_visuals_iterator(depth_iter.data);
+ visual_iter.rem; xcb_visualtype_next (&visual_iter))
+ return visual_iter.data->visual_id;
+
+ return XCB_COPY_FROM_PARENT;
+}
+
/** Manage a new client.
* \param w The window.
* \param wgeom Window geometry.
@@ -1424,6 +1454,40 @@ client_manage(xcb_window_t w, xcb_get_geometry_reply_t *wgeom, xcb_get_window_at
globalconf.default_cmap
});
+ /* is a container window needed? */
+ c->container_window = XCB_NONE;
+ if (wgeom->depth != globalconf.default_depth) {
+ /* The window has a different depth than the window that we would put it
+ * in. If it also has a ParentRelative background, ReparentWindow would
+ * fail so check for that. We cannot check for that so assume the worst.
+ */
+ xcb_colormap_t colormap;
+ xcb_visualid_t visual = pick_visual_for_depth(wgeom->depth);
+
+ if (wgeom->depth == globalconf.screen->root_depth)
+ colormap = globalconf.screen->default_colormap;
+ else
+ {
+ colormap = xcb_generate_id(globalconf.connection);
+ xcb_create_colormap(globalconf.connection, XCB_COLORMAP_ALLOC_NONE,
+ colormap, globalconf.screen->root, visual);
+ }
+
+ c->container_window = xcb_generate_id(globalconf.connection);
+ xcb_create_window(globalconf.connection, wgeom->depth, c->container_window, c->frame_window,
+ 0, 0, wgeom->width, wgeom->height, 0, XCB_COPY_FROM_PARENT,
+ visual, XCB_CW_BACK_PIXEL | XCB_CW_BORDER_PIXEL | XCB_CW_COLORMAP,
+ (const uint32_t[]) {
+ globalconf.screen->black_pixel,
+ globalconf.screen->black_pixel,
+ colormap
+ });
+ xcb_map_window(globalconf.connection, c->container_window);
+
+ if (colormap != globalconf.screen->default_colormap)
+ xcb_free_colormap(globalconf.connection, colormap);
+ }
+
/* The client may already be mapped, thus we must be sure that we don't send
* ourselves an UnmapNotify due to the xcb_reparent_window().
*
@@ -1436,7 +1500,10 @@ client_manage(xcb_window_t w, xcb_get_geometry_reply_t *wgeom, xcb_get_window_at
globalconf.screen->root,
XCB_CW_EVENT_MASK,
no_event);
- xcb_reparent_window(globalconf.connection, w, c->frame_window, 0, 0);
+ if (c->container_window != XCB_NONE)
+ xcb_reparent_window(globalconf.connection, w, c->container_window, 0, 0);
+ else
+ xcb_reparent_window(globalconf.connection, w, c->frame_window, 0, 0);
xcb_map_window(globalconf.connection, w);
xcb_change_window_attributes(globalconf.connection,
globalconf.screen->root,
@@ -2215,6 +2282,7 @@ client_unmanage(client_t *c, bool window_valid)
if (c->nofocus_window != XCB_NONE)
window_array_append(&globalconf.destroy_later_windows, c->nofocus_window);
+ /* container_window is automatically destroyed when its parent is destroyed */
window_array_append(&globalconf.destroy_later_windows, c->frame_window);
if(window_valid)
diff --git a/objects/client.h b/objects/client.h
index ee7384988..f38c5a253 100644
--- a/objects/client.h
+++ b/objects/client.h
@@ -51,6 +51,8 @@ typedef enum {
struct client_t
{
WINDOW_OBJECT_HEADER
+ /** Window we use as a container for windows with non-default depth */
+ xcb_window_t container_window;
/** Window we use for input focus and no-input clients */
xcb_window_t nofocus_window;
/** Client logical screen */ |
|
All 3 points seem to work for me (with GNOME/gtk@2ce63a8 and patch on master). Tell me if I missed something / if you need more tests. |
|
@alfunx Thanks a lot. Sorry to ask you again, but could you test #2280? This sets visual, XCB_CW_BACK_PIXEL | XCB_CW_BORDER_PIXEL | XCB_CW_COLORMAP,
(const uint32_t[]) {
globalconf.screen->black_pixel,
globalconf.screen->black_pixel,
colormap
});into visual, XCB_CW_BACK_PIXMAP | XCB_CW_BORDER_PIXEL | XCB_CW_COLORMAP,
(const uint32_t[]) {
XCB_BACK_PIXMAP_NONE,
globalconf.screen->black_pixel,
colormap
}); |
Apparently, Gtk started giving its windows a ParentRelative background. This means that Gtk's windows can only be reparented into windows with the same depth. Since we want working transparency in titlebars, we however use a window with depth 32 to reparent clients into. Thus, ReparentWindow would fail and Gtk's window would just be always visible. We fix this by creating a useless container window of the same depth as the client window. Instead of reparenting client windows directly into the window used for titlebars, they are reparented into this container window and the container window is put into the window used for titlebars. Let's see how long it takes someone to find some program that gets confused when the WM reparents its window into a window contained in another window, instead of just one window... Fixes: awesomeWM#2279 Signed-off-by: Uli Schlachter <psychon@znc.in>
|
Can any of you upgrade your GTK to the latest git (3.24 beta) and report if the issue is fixed? |
|
@Elv13 Can't reproduce this issue with GNOME/gtk@5afc01d (branch |
|
Horray! Thanks to everyone who use the |
When a new client appears, we reparent its window into a window of our choice so that we can add decorations. However, windows can be difficult making the reparenting fail. For example, some snapshots of GTK+ set a parent-relative background, which means that its parent windows have to have the same depth as the window itself. This makes reparenting fail if transparency is used/supported. Make the failure mode... different, by checking if reparenting succeeded. If it failed, we print an error message and unmanage the window immediately. This means that those GTK+ windows just do not appear at all, instead of behaving weirdly. This idea of this patch came from i3. Related-to: awesomeWM#2279 Signed-off-by: Uli Schlachter <psychon@znc.in>
When a new client appears, we reparent its window into a window of our choice so that we can add decorations. However, windows can be difficult making the reparenting fail. For example, some snapshots of GTK+ set a parent-relative background, which means that its parent windows have to have the same depth as the window itself. This makes reparenting fail if transparency is used/supported. Make the failure mode... different, by checking if reparenting succeeded. If it failed, we print an error message and unmanage the window immediately. This means that those GTK+ windows just do not appear at all, instead of behaving weirdly. This idea of this patch came from i3. Related-to: awesomeWM#2279 Signed-off-by: Uli Schlachter <psychon@znc.in>
|
Apparently Manjaro Linux patches their GTK+ so that stuff breaks there (according to https://gitlab.gnome.org/GNOME/gtk/issues/1134#note_265753) |
|
Yes they are explicitly patching GTK with GNOME/gtk@2ce63a86: https://github.com/manjaro/packages-extra/blob/master/gtk3-classic/PKGBUILD#L64 (which is not the case in the Arch package). |
|
@alfunx By default Manjaro uses vanilla GTK3 package. Some community editions are using |
|
Life is awesome again ! 🎉 First we are world champions 🇫🇷 ! |
|
Please note there is no problem with gtk3-classic/mushrooms. gtk3-classic/mushrooms uses patch, which will be part of next gtk3 release, |
|
@TomaszGasior I don't think so. Could you show me the patch you are referring to? In case you mean the patch with |
|
Okay. So it gtk3-mushrooms causes bug in Awesome, I will look at this and I will fix it. Probably tomorrow. |
|
@psychon @ameuret @alfunx @Elv13 I'm sorry for my mistake and delayed reaction. Currently (lah7/gtk3-classic@fba94ac) On the other hand, I am very sorry when you are calling my work on |
|
@TomaszGasior Sorry if I offended you. That was not my intention. I only wanted to say that Manjaro applies a patch to their GTK+ that makes the problem happen while upstream GTK+ does not make the problem happen (and I have since learned that this statement is actually wrong since there are two GTK+ versions in Manjaro...). I'm sorry for sounding like I wanted to assign blame. |
When a new client appears, we reparent its window into a window of our choice so that we can add decorations. However, windows can be difficult making the reparenting fail. For example, some snapshots of GTK+ set a parent-relative background, which means that its parent windows have to have the same depth as the window itself. This makes reparenting fail if transparency is used/supported. Make the failure mode... different, by checking if reparenting succeeded. If it failed, we print an error message and unmanage the window immediately. This means that those GTK+ windows just do not appear at all, instead of behaving weirdly. This idea of this patch came from i3. Related-to: awesomeWM#2279 Signed-off-by: Uli Schlachter <psychon@znc.in>
When a new client appears, we reparent its window into a window of our choice so that we can add decorations. However, windows can be difficult making the reparenting fail. For example, some snapshots of GTK+ set a parent-relative background, which means that its parent windows have to have the same depth as the window itself. This makes reparenting fail if transparency is used/supported. Make the failure mode... different, by checking if reparenting succeeded. If it failed, we print an error message and unmanage the window immediately. This means that those GTK+ windows just do not appear at all, instead of behaving weirdly. This idea of this patch came from i3. Related-to: #2279 Signed-off-by: Uli Schlachter <psychon@znc.in>
When a new client appears, we reparent its window into a window of our choice so that we can add decorations. However, windows can be difficult making the reparenting fail. For example, some snapshots of GTK+ set a parent-relative background, which means that its parent windows have to have the same depth as the window itself. This makes reparenting fail if transparency is used/supported. Make the failure mode... different, by checking if reparenting succeeded. If it failed, we print an error message and unmanage the window immediately. This means that those GTK+ windows just do not appear at all, instead of behaving weirdly. This idea of this patch came from i3. Related-to: awesomeWM#2279 Signed-off-by: Uli Schlachter <psychon@znc.in>
Output of
awesome --version:awesome v4.2 (Human after all)
• Compiled against Lua 5.3.4 (running with Lua 5.3)
• D-Bus support: ✔
• execinfo support: ✔
• xcb-randr version: 1.5
• LGI version: 0.9.2
How to reproduce the issue:
Start firefox 60 or thunderbird 52 in tile layout
Actual result:
Firefox/Thunderbird positions itself above the menubar
Expected result:
Window should be below the menu bar
Setting/Unsetting floating does not help either. Also it is present on all tags at once.
The text was updated successfully, but these errors were encountered: