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.
Yes, I do see that too.
Created attachment 1666954 [details] screencast Had to add screencast if I already made it :)
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.
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...
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
Can you try this build? https://koji.fedoraproject.org/koji/taskinfo?taskID=42179399 Thanks.
(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!
Yep, fixes it for me too.
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.
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)
(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.
(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?
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
Wow, yeah, I see the same behaviour with virt-manager. OK, let's file that somewhere else, GNOME-y.
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).
This is all resolved now in current F32 stable I believe.