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 751887 - wayland: gtk windows always show up on primary monitor in top-left corner
wayland: gtk windows always show up on primary monitor in top-left corner
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: wayland
git master
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
: 757560 (view as bug list)
Depends on:
Blocks: WaylandRelated
 
 
Reported: 2015-07-03 09:39 UTC by Marek Chalupa
Modified: 2015-11-16 02:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Set size hints for new wayland windows (1.12 KB, patch)
2015-07-03 10:03 UTC, Marek Chalupa
none Details | Review
Do not force placing window if it is not mapped (1.40 KB, patch)
2015-07-10 15:34 UTC, Marek Chalupa
none Details | Review
Do not force placing window if it has no buffer under wayland yet (1.45 KB, patch)
2015-08-06 14:14 UTC, Marek Chalupa
committed Details | Review

Description Marek Chalupa 2015-07-03 09:39:11 UTC
All gtk windows under wayland show up on primary monitor in the top-left corner, no matter where you open them (i. e. secondary monitor). This is due to race - the window is queued for showing and then it gets request for geometry. If the request is fast enough, the window is unqueued and positioned after this request, which is fine. In the other case, the idle move and resize in queue takes action before geometry request, and places the window taking its size 0x0, which breaks computing the placement.
Comment 1 Marek Chalupa 2015-07-03 10:03:39 UTC
Created attachment 306690 [details] [review]
Set size hints for new wayland windows

Tried to dig into the positioning more, but that brought me only headache. This is quick and simple.
Comment 2 Jonas Ådahl 2015-07-03 10:13:02 UTC
Review of attachment 306690 [details] [review]:

::: src/wayland/meta-window-wayland.c
@@ +352,3 @@
+   * The window will set its own size later via request */
+  attrs.width = 200;
+  attrs.height = 100;

Would it maybe be more reasonable to wait with creating the MetaWindow until proper attributes can be configured, i.e. not until after the first attached buffer is committed? Either that or support putting of initial mapping until so is the case. Having arbitrary initial size values doesn't seem like the best solution.
Comment 3 Owen Taylor 2015-07-06 14:24:15 UTC
Review of attachment 306690 [details] [review]:

Seems like picking an arbitrary size could result in placement bugs - e.g., Mutter decides that the nice 300x300 gap in the lower left corner of the screen is the perfect place to put a 200x100 window, then it gets resized bigger and is mostly off the screen. I can't imagine that this is the correct approach.

It seems that *roughly* we should:
 - If placement is run when there is no buffer attached, return early and don't do it
 - Force placement when the buffer is attached if not already done
Comment 4 Marek Chalupa 2015-07-10 15:34:06 UTC
Created attachment 307232 [details] [review]
Do not force placing window if it is not mapped
Comment 5 Rui Matos 2015-08-04 15:45:23 UTC
Review of attachment 307232 [details] [review]:

::: src/core/window.c
@@ +1571,2 @@
        */
+      if (!window->placed && window->mapped)

This basically invalidates the purpose of this _force_placement() since window->mapped will always be false for the case where it matters (i.e. an X11 window that comes up minimized) and thus we'll never place it as intended here.

I think a better check than window->mapped here would be client_window_should_be_mapped (window) since this will let us skip the force_placement() for bufferless wayland windows but still do it for minimized X11 ones.
Comment 6 Jasper St. Pierre (not reading bugmail) 2015-08-04 16:23:09 UTC
(In reply to Rui Matos from comment #5)
> Review of attachment 307232 [details] [review] [review]:
> 
> ::: src/core/window.c
> @@ +1571,2 @@
>         */
> +      if (!window->placed && window->mapped)
> 
> This basically invalidates the purpose of this _force_placement() since
> window->mapped will always be false for the case where it matters (i.e. an
> X11 window that comes up minimized) and thus we'll never place it as
> intended here.

Are minimized windows unmapped? They should be mapped...
Comment 7 Rui Matos 2015-08-05 16:34:11 UTC
(In reply to Jasper St. Pierre from comment #6)
> Are minimized windows unmapped? They should be mapped...

Yes, initially they are. Mutter maps them later, but when this function runs for the first time they are still unmapped. That's why I suggested checking client_window_should_be_mapped() since that will actually be true in this case while window->mapped is still false.
Comment 8 Marek Chalupa 2015-08-06 14:14:15 UTC
Created attachment 308853 [details] [review]
Do not force placing window if it has no buffer under wayland yet
Comment 9 Rui Matos 2015-08-07 11:34:41 UTC
Review of attachment 308853 [details] [review]:

Let's go with this
Comment 10 Kamil Páral 2015-11-11 13:18:27 UTC
I still see this (or similar) issue with:
mutter-3.18.1-4.fc23.x86_64
gnome-shell-3.18.1-1.fc23.x86_64

I have secondary monitor on the left side and primary monitor on the right side. Nautilus is opened in 70% cases on the left monitor, in 30% cases on the right monitor (always in the very top left corner). Gnome terminal is always opened on the left monitor. This is regardless of where the mouse cursor is and where the app was the last time I closed it.
Comment 11 Jonas Ådahl 2015-11-16 02:19:34 UTC
*** Bug 757560 has been marked as a duplicate of this bug. ***