Bug 1809107
| Summary: | Maximize doesn't work on GNOME Wayland, moves window partly off-screen | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | František Zatloukal <fzatlouk> |
| Component: | firefox | Assignee: | Martin Stransky <stransky> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | 0xalen+redhat, anto.trande, awilliam, elxreno, fzatlouk, gecko-bugs-nobody, gmarr, jhorak, john.j5live, kengert, lruzicka, pjasicek, rhughes, robatino, rstrode, sandmann, stransky |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | AcceptedBlocker | ||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-03-16 16:44:47 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1705305 | ||
| Attachments: | |||
|
Description
František Zatloukal
2020-03-02 13:03:03 UTC
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. |