Description of problem: As shown in the attached screencast,nothing happens after click the default selected "keep changes" button,or the "revert settings" button. Version-Release number of selected component (if applicable): gnome-settings-daemon-41~rc-2.fc35.x86_64 gnome-shell-41~rc.1-2.fc35.x86_64 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 1825252 [details] screencast
Proposed as a Blocker for 35-final by Fedora user lnie using the blocker tracking app because: All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test.
I tested this in a VM and twice it worked just fine. But the third time, I couldn't click any of those "Keep"/"Revert" buttons. But I could confirm them with a keyboard, though. I quickly found the reason why the mouse didn't work for me - my mouse cursor position desynchronized with what the VM thought my cursor position was. So while I saw my cursor somewhere, the VM registered click somewhat higher and to the left. That's why I couldn't confirm the buttons, and couldn't work with the VM at all afterwards - my mouse cursor position was permanently shifted (until reboot). This looks like a problem in spice agent or similar.
As probably expected, this doesn't seem to affect bare metal, only VMs.
Reassigning to spice-vdagent for further investigation.
I am not sure if my experience is somehow connected with this bug, but I also spotted some weird behaviour when I changed the resolution to match my real resolution -> I thought I could not click on the buttons (as described), but then I discovered that the click location was fine and that there was a delay of about 20-30 seconds before the VM UI started to show any response. When I changed the resolution back to something lower, the situation improved significantly.
I see this constantly and it drives me nuts. It's most obvious when you're selecting text in a console in the VM. I used to only see/notice it in KDE, where it seems to happen on every boot, but lately I've been noticing it in GNOME VMs too.
Discussed during the 2021-09-27 blocker review meeting: [0] The decision to delay the classification of this as a blocker bug was made as this is definitely an aggravating bug, but whether it's bad enough to consider a violation of the criteria seems like a tight call and the vote is not clear yet. It would be useful to have more details about the bug to make the decision (e.g. whether it's really happening more often/in more circumstances than it used to). [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-09-27/f35-blocker-review.2021-09-27-16.00.txt
(In reply to Adam Williamson from comment #7) > I see this constantly and it drives me nuts. It's most obvious when you're > selecting text in a console in the VM. I used to only see/notice it in KDE, > where it seems to happen on every boot, but lately I've been noticing it in > GNOME VMs too. I believe this is a related, but possibly different bug. I reported bug 2009304 to cover the initial "small" offset which seems to be present every time. I'll use this bug report to demonstrate that the offset changes wildly when changing resolutions.
Created attachment 1827652 [details] switching resolutions demonstration In this video you can see how the cursor offset changes *substantially* (and also randomly) after a resolution switch. The offset seems to move in any random direction and a random distance from the proper location. When the offset gets large, I'm no longer able to control any UI with my mouse and need to resort to keyboard shortcuts only, because I have no idea where the cursor actually is. Note that while I was changing the resolution manually in the video, it is possible that this problem also occurs when the VM changes the resolution dynamically based on the window size. However, I couldn't reproduce the bug in this case. Similarly to bug 2009304, I only saw this problem when using Wayland in the VM. After switching to X11, it worked fine.
since we're blaming spice-vdagent here, has anyone tested to see if it happens if you remove that?
I can confirm that removing spice-vdagent-0.21.0-5.fc35.x86_64 from the VM guest completely resolves this problem. The slight cursor offset (bug 2009304) persists, but it no longer changes when resolutions are switched.
Discussed during the 2021-10-04 blocker review meeting: [1] The decision to classify this bug as an RejectedBlocker and AcceptedFreezeException was made: "This is rejected as a blocker on the basis that changing resolutions in a VM such that the bug happens is not commonly done (we may reconsider based on plausible arguments to the contrary). accepted as a freeze exception issue if the fix needs to be in the guest, so that release lives may be fixed." [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2021-10-04/f35-blocker-review.2021-10-04-16.02.log.html
I tested this with Fedora-Workstation-Live-x86_64-36_Beta-1.1.iso (spice-vdagent-0.22.1-1.fc36.x86_64) and I no longer see this issue.
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
spice-vdagent did get updated to 0.22.1 in F35: https://bodhi.fedoraproject.org/updates/FEDORA-2022-f666b4aeb8 so i'm gonna say this was fixed (though probably not on the release media).