Bug 1809107 - Maximize doesn't work on GNOME Wayland, moves window partly off-screen
Summary: Maximize doesn't work on GNOME Wayland, moves window partly off-screen
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F32FinalBlocker, FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2020-03-02 13:03 UTC by František Zatloukal
Modified: 2020-03-16 16:44 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-03-16 16:44:47 UTC
Type: Bug


Attachments (Terms of Use)
screencast (4.65 MB, video/webm)
2020-03-02 13:06 UTC, František Zatloukal
no flags Details
screenshot of the new issue (right-click menu appearing on the left-hand monitor, even though I right-clicked with the cursor in the middle of the right-hand monitor) (684.86 KB, image/png)
2020-03-05 20:47 UTC, Adam Williamson
no flags Details

Description František Zatloukal 2020-03-02 13:03:03 UTC
Description of problem:
After maximizing Firefox window in GNOME Wayland sessions, it gets maximized and also moved a little bit off-screen.

This works just fine in Xorg session.

Version-Release number of selected component (if applicable):
firefox-72.0.2-3.fc32.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Log in into F32 GNOME (Wayland)
2. Open Firefox
3. Try to maximize (either double click on title bar or win + up)

Actual results:
Firefox window gets maximized, but is also moved a little bit off-screen.

Expected results:
Maximize should work on both Xorg and Wayland sessions without moving a window off-screen.

Additional info:
Tested in VM with virgl, will test other combinations later.

Comment 1 Martin Stransky 2020-03-02 13:04:30 UTC
Yes, I do see that too.

Comment 2 František Zatloukal 2020-03-02 13:06:45 UTC
Created attachment 1666954 [details]
screencast

Had to add screencast if I already made it :)

Comment 3 Fedora Blocker Bugs Application 2020-03-02 13:09:32 UTC
Proposed as a Blocker for 32-final by Fedora user frantisekz using the blocker tracking app because:

 I guess I can use "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test." here.

Comment 4 Adam Williamson 2020-03-02 15:55:51 UTC
You can get it to maximize correctly, it's just awkward. You have to grab the top-left corner of the window and drag it exactly to the top-left corner of the screen.

I've been dealing with this for weeks but hadn't got around to filing a bug on it yet (I went to do it the other day and messed up my video recording of it, sigh). I'd actually been assuming it was specific to my weird dual-vertical-monitors configuration since no-one else had mentioned it (I also have an annoying bug where sometimes one monitor can get stuck displaying a Firefox window's content even when that's not what should be visible there now - only way to resolve it is to switch to a VT and back).

I'm probably +1 final blocker for this, but we don't really have a great criterion, maybe we need one for basic window management functions...

Comment 5 Geoffrey Marr 2020-03-02 20:26:57 UTC
Discussed during the 2020-03-02 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criterion:


"All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test", this is held to be 'basic functionality' for a commonly-used app like Firefox.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-03-02/f32-blocker-review.2020-03-02-17.00.txt

Comment 6 Martin Stransky 2020-03-04 15:11:54 UTC
Can you try this build?
https://koji.fedoraproject.org/koji/taskinfo?taskID=42179399
Thanks.

Comment 7 František Zatloukal 2020-03-04 15:31:24 UTC
(In reply to Martin Stransky from comment #6)
> Can you try this build?
> https://koji.fedoraproject.org/koji/taskinfo?taskID=42179399
> Thanks.

Yes, this fixes the issue. Thanks!

Comment 8 Adam Williamson 2020-03-04 17:39:19 UTC
Yep, fixes it for me too.

Comment 9 Adam Williamson 2020-03-05 20:46:45 UTC
Although I'll note I got an odd bug in exchange: when I have Firefox maximized on my right-hand monitor (which is my usual set up), things that 'pop up' - like the right click menu, for instance, or the BitWarden plugin menu when I click on the icon in the URL bar - appear glued to the right-hand side of the left-hand monitor. See attachment.

Comment 10 Adam Williamson 2020-03-05 20:47:28 UTC
Created attachment 1667913 [details]
screenshot of the new issue (right-click menu appearing on the left-hand monitor, even though I right-clicked with the cursor in the middle of the right-hand monitor)

Comment 11 Martin Stransky 2020-03-06 07:12:30 UTC
(In reply to Adam Williamson from comment #10)
> Created attachment 1667913 [details]
> screenshot of the new issue (right-click menu appearing on the left-hand
> monitor, even though I right-clicked with the cursor in the middle of the
> right-hand monitor)

Hi Adam, please file a new bug for it. Jan Horak works tirelessly on the popup issues and he may be able to help.
Thanks.

Comment 12 František Zatloukal 2020-03-06 13:11:19 UTC
(In reply to Adam Williamson from comment #10)
> Created attachment 1667913 [details]
> screenshot of the new issue (right-click menu appearing on the left-hand
> monitor, even though I right-clicked with the cursor in the middle of the
> right-hand monitor)

Lukas Ruzicka observed similar issues with right click menu in virt-manager in F32. So it might be a problem in GTK?

Comment 13 Lukas Ruzicka 2020-03-06 13:16:08 UTC
I am experiencing a similar issue with pop-up windows, where the windows appear on a different monitor that their parent window. This happens with many applications, but most severe it is with Virtual Manager, because if its window is not maximizied, it does not show pop-up windows at all. 

Trying to get the window will throw a line in journal: 

Mar 06 13:47:01 elefant gnome-shell[2414]: Buggy client caused popup to be placed outside of parent window

Comment 14 Adam Williamson 2020-03-06 15:53:21 UTC
Wow, yeah, I see the same behaviour with virt-manager. OK, let's file that somewhere else, GNOME-y.

Comment 15 Adam Williamson 2020-03-06 16:18:21 UTC
Filed https://gitlab.gnome.org/GNOME/mutter/issues/1098 , with I think a correct description of the bug (the issue you identified as being specific to virt-manager isn't, instead I think the key thing is whether the window is touching the shared edge of the secondary display or not).

Comment 16 Adam Williamson 2020-03-16 16:44:47 UTC
This is all resolved now in current F32 stable I believe.


Note You need to log in before you can comment on or make changes to this bug.