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 748478 - wayland: dragging window to top with multiple monitors maximizes it on originating monitor
wayland: dragging window to top with multiple monitors maximizes it on origin...
Status: RESOLVED FIXED
Product: mutter
Classification: Core
Component: general
3.16.x
Other Linux
: Normal normal
: ---
Assigned To: mutter-maint
mutter-maint
Depends on:
Blocks:
 
 
Reported: 2015-04-26 09:59 UTC by Lasse Schuirmann
Modified: 2015-04-30 12:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screencast of issue reproduction (1.24 MB, video/mp4)
2015-04-26 09:59 UTC, Lasse Schuirmann
  Details
core/events: Invalidate monitor cache when we're a wayland compositor (1.26 KB, patch)
2015-04-29 14:31 UTC, Rui Matos
committed Details | Review

Description Lasse Schuirmann 2015-04-26 09:59:53 UTC
Created attachment 302365 [details]
screencast of issue reproduction

Steps to reproduce:

Prerequisites:
 * plug in at least two monitors to your PC
 * start GNOME session with wayland from GDM
Then:
 * Open a window
 * Drag it over to the top of another monitor

Expected Results:
It maximizes on the other monitor.

Actual Results:
It maximizes on the monitor where it was before the dragging began.

Also see appended video.
Comment 1 Lasse Schuirmann 2015-04-26 10:06:01 UTC
I just noticed this only happens to some windows.

It happens with:
 * gnome-terminal
 * gnome-calendar
 * gedit
 * gnome-boxes
 * brasero

It doesn't happen with:
 * PyCharm
 * Chrome
 * Firefox
 * VLC
 * gimp

Even with this small test set leads to the conclusion that this somehow primarily affects GNOME applications...
Comment 2 Rui Matos 2015-04-29 14:31:58 UTC
Created attachment 302570 [details] [review]
core/events: Invalidate monitor cache when we're a wayland compositor

When running as an X11 compositor we do this for every event we see on
the X event stream. As a wayland compositor we don't go through that
code path but since we see all events we can easily do this on motion
events.

In fact, we don't even need this caching when we're a wayland
compositor since we can always find where the pointer is without a
round trip but we're sharing the current monitor logic with the X
path so let's keep it as is for now.
Comment 3 Jasper St. Pierre (not reading bugmail) 2015-04-29 16:43:10 UTC
Review of attachment 302570 [details] [review]:

Uh, I'm confused, we don't do a round-trip even under X11, right? It's just some local math about monitor rectangles. It only needs to be invalidated on pointer motion.

https://git.gnome.org/browse/mutter/tree/src/core/screen.c#n1634
Comment 4 Rui Matos 2015-04-29 17:02:47 UTC
(In reply to Jasper St. Pierre from comment #3)
> Review of attachment 302570 [details] [review] [review]:
> 
> Uh, I'm confused, we don't do a round-trip even under X11, right? It's just
> some local math about monitor rectangles. It only needs to be invalidated on
> pointer motion.
> 
> https://git.gnome.org/browse/mutter/tree/src/core/screen.c#n1634

Look at the function below that one, meta_screen_get_current_monitor(), it round trips on X11 through meta_cursor_tracker_get_pointer().

Other callers of meta_screen_get_current_monitor_for_pos() like window.c:update_move(), which is where the bug reported here happens, already have coords so they don't need the round trip.
Comment 5 Jasper St. Pierre (not reading bugmail) 2015-04-29 17:27:04 UTC
Review of attachment 302570 [details] [review]:

Ah, right. I still think this is a bit silly, but let's go with it.
Comment 6 Rui Matos 2015-04-30 12:02:56 UTC
7bdd698..7f0ed14  gnome-3-16 -> gnome-3-16
      7eca43c..d478d8f  master -> master

Attachment 302570 [details] pushed as d478d8f - core/events: Invalidate monitor cache when we're a wayland compositor