Upgrading to Fedora WorkStation 31 causes loss of mouse focus on apps

Greetings.
As stated above, just upgraded to Fedora 31, and have a minor annoyance now.

  • I was logged in with my primary user account (there are seven accounts total) when I made the upgrade. All appeared to be normal with the process. However, upon reboot/logging back in I find that this users desktop is not functioning correctly. I can hover over and select/use items on the top bar. But, once I hover over Applications, the app slide-out stays out. I can select an app, but cannot use it. The mouse does not gain focus within any app. I can go to the bar at the bottom of the display, and right-click to close an app just fine. I can click display upper right corner button, and log out. It just seems there is no focus from the mouse on any application.

I’ve tried Wayland and Xorg, both end in same defective results. Classic, however, works fine.

None of the other user accounts on the machine have this issue; just the one that was logged in when the upgrade occurred.

Logging in to that user with an ssh -X session from a different machine, I can open/close/use all the apps just fine. Operationally, everything seems fine. Appears that its pointing towards a display manager issue, but can’t get my hands around it.

I’ve looked through logs and don’t see anything that points obviously to anything related to this. All settings related to “focus” are set to their defaults. I guess I won’t be too disappointed it I am relegated to Classic version, but would like to solve it for the learning lesson of it all.

    inxi -Fxz
System:    Kernel: 5.6.7-200.fc31.x86_64 x86_64 bits: 64 compiler: gcc v: 9.3.1 Desktop: Gnome 3.34.5 
           Distro: Fedora release 31 (Thirty One) 
Machine:   Type: Desktop System: Dell product: OptiPlex 960 v: N/A serial: <filter> 
           Mobo: Dell model: 0G261D v: A00 serial: <filter> BIOS: Dell v: A13 date: 10/27/2011 
CPU:       Topology: Dual Core model: Intel Core2 Duo E8500 bits: 64 type: MCP arch: Penryn rev: A 
           L2 cache: 6144 KiB 
           flags: lm nx pae sse sse2 sse3 sse4_1 ssse3 bogomips: 12634 
           Speed: 2122 MHz min/max: N/A Core speeds (MHz): 1: 2122 2: 2032 
Graphics:  Device-1: Intel 4 Series Integrated Graphics vendor: Dell driver: i915 v: kernel 
           bus ID: 00:02.0 
           Display: x11 server: Fedora Project X.org 1.20.6 driver: i915 resolution: 1280x1024~60Hz 
           OpenGL: renderer: Mesa DRI Intel Q45/Q43 v: 2.1 Mesa 19.2.8 direct render: Yes 
Audio:     Device-1: Intel 82801JD/DO HD Audio vendor: Dell driver: snd_hda_intel v: kernel 
           bus ID: 00:1b.0 
           Sound Server: ALSA v: k5.6.7-200.fc31.x86_64 
Network:   Device-1: Intel 82567LM-3 Gigabit Network vendor: Dell driver: e1000e v: 3.2.6-k 
           port: ece0 bus ID: 00:19.0 
           IF: enp0s25 state: up speed: 1000 Mbps duplex: full mac: <filter> 
Drives:    Local Storage: total: 931.51 GiB used: 44.46 GiB (4.8%) 
           ID-1: /dev/sda vendor: Seagate model: ST1000DM010-2EP102 size: 931.51 GiB 
RAID:      Hardware-1: Intel SATA Controller [RAID mode] driver: ahci v: 3.0 bus ID: 00:1f.2 
Partition: ID-1: / size: 28.71 GiB used: 16.26 GiB (56.6%) fs: ext4 dev: /dev/sda5 
           ID-2: swap-1 size: 5.86 GiB used: 4.8 MiB (0.1%) fs: swap dev: /dev/sda9 
Sensors:   System Temperatures: cpu: 27.0 C mobo: N/A 
           Fan Speeds (RPM): N/A 
Info:      Processes: 202 Uptime: 37m Memory: 2.86 GiB used: 1.08 GiB (37.8%) Init: systemd 
           runlevel: 5 Compilers: gcc: 9.3.1 Shell: bash v: 5.0.11 inxi: 3.0.38
1 Like

Would you happen to have any gnome-shell extensions installed from extensions.gnome.org by any chance? It does sound a lot like what might happen if you have extensions installed for an older version of gnome-shell.

If you are unable to launch a terminal when you log in, you can ssh to your system and watch the logs as things unfold with something like
journalctl --no-pager --no-hostname -f

If you see errors related to any locally installed extensions, you can remove them with
rm -rf ~/.local/share/gnome-shell/extensions/<extension folder>

If the problem is caused by something else, messages in system logs (the ones you get with journalctl) should help you pinpoint its source.

Hi Alexpl,

Thanks for responding! You know, I had seen it in my errors, but in my ignorance kept glossing over it. I do believe it was the workspace docker extension. Removed a couple others first…didn’t help. Then removed it, and it worked as expected.

I have other quirks now, that I’ll try to get sorted out, and post new if I get stuck. Briefly, here’s what I’m seeing:

  • Firefox, when opening it, defaults to workspace 2 instead of current workspace.

  • Keyboard button shortcuts–not being interpreted correctly; ie, setting volume up/down–I can get one or the other to work, but then the opposite does something totally random (in this case, opposite button opens Rythmbox.)

  • This is the biggie: Logout option has persistent failure mode. Logging out from rebooted system session, results in being left a black screen, with tiny cursor in the corner. (however, going over to tty2, I can “startx” and have a complete session, logout, and be brought back to my tty2 prompt.) Below is journalctl output for that first session failure:

          May 03 17:40:22 xdg-desktop-por[3417]: Failed to create file chooser proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.gtk: Timeout was reached
      May 03 17:40:22 xdg-desktop-por[3417]: No skeleton to export
      May 03 17:40:29 geoclue[905]: Service not used for 60 seconds. Shutting down..
      May 03 17:40:29 systemd[1]: geoclue.service: Succeeded.
      May 03 17:40:29 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=geoclue comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
      May 03 17:40:47 xdg-desktop-por[3417]: Failed to create app chooser proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.gtk: Timeout was reached
      May 03 17:40:47 xdg-desktop-por[3417]: No skeleton to export
      May 03 17:41:00 systemd[1148]: xdg-desktop-portal.service: start operation timed out. Terminating.
      May 03 17:41:00 systemd[1148]: xdg-desktop-portal.service: Failed with result 'timeout'.
      May 03 17:41:00 systemd[1148]: Failed to start Portal service.
    

Thank you again for responding.

Regards,

Eric

Wow, you’ve got quite the collection there…

Do you have a multi-monitor setup or are you talking about the second virtual desktop/workspace?

If you go to “Keyboard Shortcuts” in Settings, is everything properly defined and unique? Can you try deleting a shortcut that malfunctions and adding it back?
If you run xev in a terminal, when you press different keys, do they produce the expected codes?

The errors you’ve pasted here have something to do with flatpaks, I fail to see how they could be related to your session problems. Do you use GDM as your display manager? When you logout and the screen blacks out, what is the status of the gdm service? (systemctl status gdm.service)
If you restart gdm (systemctl restart gdm.service), do you get back to a login prompt? Does this happen with every user on your system?

Hi Alexpl,

Q1: Yes, I was referring to the second virtural space (Workspace 1/2)

Q2: I tried using xev, and it seemed like it was telling me the same thing for the limited selection of buttons I have (older PS2 keyboard, with buttons: interet/email/searchvol-/vol+/mute. This is my testing PC, built of older components.) I closed xev, then went to Keyboard Shortcuts, and the system hard-froze in pretty short order. Cycled the power/booted up, and all the buttons worked correctly. Rebooted again, and they got a little confused again. Functions are there, they just seem to randomly change button position during reboots. I’m not too worried about this malfunction.

Q3: Yes, using GDM. When logging out, orginal session on tty1 gets stuck on black screen/cursor. Going to tty2, and entering systemctl restart gdm.service, starts a new, proper login screen on tty3 or tty4. gdm.service reports good status after logging out (monitored via ssh):

â—Ź gdm.service - GNOME Display Manager
   Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled; vendor preset: enabled)
   Active: active (running) since Sun 2020-05-03 23:26:43 CDT; 7min ago
 Main PID: 2665 (gdm)
    Tasks: 3 (limit: 3472)
   Memory: 2.4M
      CPU: 132ms
   CGroup: /system.slice/gdm.service
           └─2665 /usr/sbin/gdm

May 03 23:33:54 HmLx3 gdm[2665]: GdmLocalDisplayFactory: display already created
May 03 23:33:54 HmLx3 gdm[2665]: GdmDisplay: finish display
May 03 23:33:54 HmLx3 gdm[2665]: GdmSession: Closing session
May 03 23:33:54 HmLx3 gdm[2665]: GdmSession: Stopping all conversations
May 03 23:33:54 HmLx3 gdm[2665]: GdmSessionWorkerJob: Stopping job pid:2926
May 03 23:33:54 HmLx3 gdm[2665]: GdmCommon: sending signal 15 to process 2926
May 03 23:33:54 HmLx3 gdm[2665]: GdmSessionWorkerJob: Waiting on process 2926
May 03 23:33:54 HmLx3 gdm[2665]: GdmCommon: process (pid:2926) done (status:0)
May 03 23:33:54 HmLx3 gdm[2665]: GdmSessionWorkerJob: SessionWorkerJob died
May 03 23:33:54 HmLx3 gdm[2665]: GdmDisplayStore: Unreffing display: 0x55d8f21233c0

Part that annoys me about this, is that logout worked several times after the upgrade when I started troubleshooting the original issue. Probably worked 10-12 times the first night; next day it didn’t logout correctly once, or since. Oh, and no, the only user that seems affected is the one that was logged in when the upgrade was performed.

I really appreciate the assistance.

Since the other accounts function properly, we know your installation is generally healthy.

Out of curiosity, do the other accounts experience the same issue with the keyboard? From my IT days, this sounds a lot like a problem with ageing components controlling the voltage/current of the bus. Power cycling restores them to levels adequate for marginal operation but rebooting drops them below what is needed for the current motherboard/keyboard combination. It was rather rare, but it happened.

For the rest of your problems I strongly suspect settings left behind from the shell extensions you’ve used. For instance, setting applications to start on a specific workspace is done with something like Auto Move Windows. Did you have that or something similar installed?

If you still have non-system extensions, I’d suggest going to extensions.gnome.org to update them for your current gnome-shell version. Be careful not to update system extensions, that can cause the same sort of problems as well.

If you have removed all of your extensions, but you remember what they were, reinstall them from the site or from gnome-software - if they are packaged in fedora - and check their settings if a simple update doesn’t solve your problems.

If you don’t remember what you had, you will have to look at individual modified GSettings values with dconf-editor and restore what might seem out of order to the default.

If all else fails, you can always transfer the user’s files to a new account, nuke that one and use usermod/chmod to adjust your groups and permissions and sort of recreate it.

Hello Alexpl,

Just got done with work and took a look at your latest response.

For extensions, the only two non-native ones I have/had were Freon and Workspaces to Dock. I’ve previously removed the workspaces one, which alleviated the issue using the Activities button. Freon is up to date, and has never given me any trouble.

Where I am at now: All user accounts appear to behave equally-- that is, all appears to currently work as it did pre-upgrade, with exception of the accessory buttons on the keyboard.

As for Firefox persistently starting up in Workspace2, I am on hold with that, as a simple search for this shows hits of users with gnome on different OS’s having the same issue…may be a developing issue still? I will monitor that one.

I agree with you that it could be keyboard voltage issues, given the age of the old thing. I checked all user accounts, and the accessory buttons have the same issue on all users. However, all was working correctly on it prior to upgrade. It seems the buttons are not interpreted correctly any longer, with respect to their actual intended function. Instead of volume up/down/mute, and search & internet buttons, they now all appear to be interpreted as media buttons: play/pause next/previous, per response received when trying to manually assign them. I’ve manually assigned vol down/mute/vol up to <Ctl+2>/5/8 respectively on the number pad for now.

I think at this point I can live without the quirky buttons, and the soft lock up with Activities has been fixed.

Only real issue left is the logout quirk. Your previous command works just fine every time, but I am puzzled why GDM can’t repopulate the screen with the login menu/user list. Seems to log the session completely out correctly, but isn’t being told to regenerate that display. There is no error, watching journalctl while logging out; looks to just finish up the session, and stop.

Your patience and responsiveness has been most appreciated. Thank you!

Regards,

Eric

Have you ever installed anything or added something to your .*rc files that allowed you to start applications in specific workspaces? Could you try reinstalling the latest version of Workspaces to Dock and see if that makes a difference? Other than the settings stored in each extension’s folder under ~/.local/share/gnome-shell/extensions/, many extensions change GSettings keys and these modifications stick around even if you remove the extension.

Well, the only other explanation I could think of would be that a different keyboard model was declared at some point, but that should also be consistent; rebooting or cold booting wouldn’t make a difference.

I don’t know which setting might lead to such behavior, perhaps if you fished around dconf-editor long enough, setting everything to the default value, eventually you could solve this. Maybe @chrismurphy has a better idea.

No I sure haven’t consciously done so.

At this point, I will not likely do that. That was the one the definitely broke invoking the Activities button. Working fine now; I believe I will resolve to not apply extensions to Fedora.

Keyboard is consistent through power cycles and reboots. I will leave it well enough alone at this point too, since the volume buttons are only a minor issue.

Well, poked around through numerous things until bleary-eyed, and saw nothing definitive. Then I found /etc/gdm/custom.conf. The line WaylandEnable=false was commented out. Uncommented it, logged out, logged back in via command input on VT2, logged back out, and is now working well for all users.

I thank you for all the many helpful insights you have given, and will call these issues resolved to my satisfaction. Thank you!

Hi Eric,

I didn’t mean to keep it forever, just install its latest version, see if that changes anything and then maybe play a bit with its settings.

Extensions are immensely useful, well at least some of them, but gnome-shell’s API and functionality change between versions. Non-system extensions can’t get updated along with the rest of the system, so it would be prudent to disable them prior to an upgrade. Deactivated extensions can be updated from the website once the refreshed system is up and running and then enabled again. I’m a bit surprised that this nugget of wisdom hasn’t been floating around.

That’s quite odd, you’re on intel graphics and if anything, Wayland’s compatibility generally improves with every release.

Oh well, if you’re happy with how things are, that’s good enough for me.

All the best.
A.

Good morning. So, I did reinstall this with matched correct version, and it seems to be working correctly now. Firefox still starts on Workspace 2, but now at least the display is automatically switched to that workspace. In my searching last night, it seems several people have minor issues with certain apps starting in a workspace they did not want it to.

I will report back if any issues arise with this extension installed, but for now this will put me back pretty much where I was before the upgrade. Thank you!

ps… I had to reinstall the chrome-gnome-shell again before I could install an extension…is that typical after an upgrade? Just curious.

Eric

Were they users of that extension?

No, I’ve never had to reinstall anything post-upgrade or chrome-gnome-shell in particular. Maybe its permissions needed tweaking in your browser? Firefox didn’t report any problems with the add-on after the upgrade though.

The ones I read, didn’t say. Just said they had problems with FIrefox or Eclipse starting in WS2 when that wasn’t desired, and no resolutions (except adding on additional apps to manage it.) I’ll skip adding things to try and fix it–It’ll give me something to pick at and figure out eventually!

1 Like

Just an idea to help with the search:

$ gsettings list-recursively | grep firefox > haystack_small
$ grep -r -I --exclude-dir={.mozilla,.cache} firefox ~/ > haystack_big
2 Likes