Shell: GUI becomes unresponsive when right-clicking Zoom icon if Dash to Dock is enabled

[jacobgkau]

Distribution (run cat /etc/os-release):
NAME="Pop!_OS"
VERSION="20.04 LTS"
ID=pop
ID_LIKE="ubuntu debian"
PRETTY_NAME="Pop!_OS 20.04 LTS"
VERSION_ID="20.04"
HOME_URL="https://system76.com/pop"
SUPPORT_URL="http://support.system76.com"
BUG_REPORT_URL="https://github.com/pop-os/pop/issues"
PRIVACY_POLICY_URL="https://system76.com/privacy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
LOGO=distributor-logo-pop-os

Related Application and/or Package Version (run apt policy pop-shell or provide the latest commit if building locally): 0.1.0\~1589925465\~20.04\~ff5f374

Issue/Bug Description: For some applications (including Zoom and Microsoft Teams), right-clicking the application icon in the launcher while Dash to Dock is enabled causes the GUI to become unresponsive (the mouse still moves, but nothing can be clicked.) A reboot is required at this point (I can restart GDM without rebooting, but then I have a login loop.)

Steps to reproduce (if you know):

• Enable Dash to Dock and Pop Shell tiling
• Install and open Zoom, sign in (which results in a single window taking up most of the screen and causing the launcher to hide)
• Resize Zoom using the mouse so the launcher is visible (window must be resized manually due to #402)
• Right-click Zoom icon

Expected behavior: Context menu for Zoom should be displayed, or at least the GUI should not freeze.

Other Notes:

• Reported by a customer in support ticket 46626.
• Since I was able to reproduce this on my own machine, I'm attaching log files from my own machine. You'll want to look before the last reboot in journalctl, around line 37000.
  system76-logs.tar.gz
• I figured this is a separate issue than #402 since this one is the interface freezing and #402 is just the launcher disappearing before anything can be clicked.

[jeffhipp]

I routinely experience this same issue with Zoom, as well as frequently when opening GitKraken (Flatpak version, FWIW) while in tiling mode. I have Dash to Dock set up to show me multiple dots when multiple application windows are open. In both cases, an extra dot is appearing next to the application icon on the dock, but when I try getting info on the mystery window by right clicking, everything freezes.

Strangely, the same thing happens when closing the OS's calculator app. The icon and dot indicator do not disappear from the dock when the window closes, and right clicking the icon causes a lockup.

[mmstick]

Try out the dev_focal branch. This may be fixed now

[rthery]

I tried today with dev_focal and I could still reproduce the issue :/

I also have the feeling that this issue and #220 have the same root cause. It seems caused by the window instance of an app not really closing. It disappears, but it will remain active in the background. I have yet to find a way to restore that window, maybe it's really closed but something is not cleaned properly causing gnome shell to believe it's still here.

When right clicking the app in the Dash or the Show Applications window, you can see an instance is still there, but clicking it will just bring you back to the workspace where it was closed without making it reappear.

If you right click it in the Dash with Dash to Dock installed, it will cause gnome-shell process to lock up 100% CPU, freezing your session except for your mouse. You'll have to Ctrl + Alt + F3 to log into your session with command line, kill gnome-shell process, then you can log back in your session through the GUI with Ctrl + Alt + F1

[mmstick]

@rthery Try again with https://github.com/pop-os/shell/pull/405/commits/45b53c8dc34a0a2f216cbd12d0fdb5128eda679c

I need a good way of reproducing this.

[rthery]

Thanks @mmstick !
I've been running 45b53c8dc34a0a2f216cbd12d0fdb5128eda679c for the whole evening as well as running specific reproduction steps I knew was causing it, with and without Dash to Dock.

Without it, I could not reproduce that bug anymore! So that's great :)

But with Dash to Dock, the issue persists. The reproduction steps are pretty easy:

1. Start a session with Dash to Dock enabled
2. Launch Extensions in the first workspace
3. Launch Files in the second workspace
4. Go to the first workspace and close Extensions
5. Go to the second workspace and close Files
6. Notice that both Extensions and Files are back in the Dash with invisible but open windows

You can find a video of the reproduction here (I wish github could accept webm video...):
https://ecloud.global/s/xzEQzWSPt6Dkwo3

If I can find some time in the coming days, I'll try to dig in the code to understand what's going on.

[mmstick]

Good to see that this shot in the dark improved this long standing issue! This last change simply requests to disconnect all signals that were connected to the window in this extension when the window is destroyed.

It should have been happening automatically by default when the window is destroyed, but I suppose there are some unavoidable cyclic references in the JavaScript bindings that make this tricky to guarantee.