GNOME Bugzilla – Bug 771482
dialogs are displayed across monitor borders
Last modified: 2021-07-05 14:07:47 UTC
If an app shows a dialog, it is often displayed across monitor borders. Which looks ugly and unprofessional, because it's very hard to read something that is split between monitors. See the video for a quick demonstration. It would be much better if the dialog was moved a bit to the right and not split between different monitors. gnome-session-wayland-session-3.21.90-1.fc25.x86_64 gnome-shell-3.21.91-1.fc25.x86_64 gtk3-3.21.5-1.fc25.x86_64 libwayland-client-1.11.93-1.fc25.x86_64 libwayland-cursor-1.11.93-1.fc25.x86_64 libwayland-server-1.11.93-1.fc25.x86_64 mesa-libwayland-egl-12.0.2-1.fc25.x86_64 mutter-3.21.91-2.fc25.x86_64
Created attachment 335614 [details] bug demonstration video This video is recorded on wayland, but the same problem happens on X11. (Although the control-center dialog is displayed at the center of the screen on X11 by default, so this is not so often visible. On wayland, the apps seem to be more often displayed in the top left border).
Created attachment 335615 [details] photo of the dialog in real world It is not obvious from the video, but in real world, the dialog looks very bad. See this photo of the actual monitors.
Created attachment 335656 [details] [review] constraints: Ensure modal dialogs aren't placed straddling monitors It looks bad otherwise.
Created attachment 335657 [details] [review] window: Keep modal dialogs in the same monitor as their parents Now that we constrain modal dialogs to a single monitor we can't blindly move them to 0,0 because that might result in them ending up in a different monitor than their parent. We also need to know if this is a user action so that the constraints code properly applies its less strict positioning rules for that case.
Created attachment 335658 [details] [review] constraints: Keep frameless windows constrained to a single monitor There's no reason frameless windows shouldn't be constrained to a single monitor. The comment here is wrong since a user action is already exempt from this constrain via the info->is_user_action check. -- This one isn't strictly related to the bug reported here. The condition just seemed wrong to me while reading the code.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.