Task lists causes all application menus to lag when there are lots of windows open

[phelps-sg]

When the task list option is enabled, if there are lots of windows open then menus throughout gnome shell start to become unresponsive. To reproduce:

• Log in to a new gnome shell session.
• Install TaskBar shell extension.
• Ensure 'Tasks' option is enabled in configuration 'Overview'
• Open a terminal window - mouse over app menus inside window - 'File', 'Edit', 'View' etc.. Response time is reasonable.
• Launch lots of other tasks (e.g. firefox) to create lots of entries in the task bar.
• Focus back on terminal application and mouse over app menus inside window - 'File', 'Edit' etc.. - Response time is very laggy.
• Disable 'Tasks' option in configuration 'Overview'
• Focus back on terminal application- menus are responsive again.

Disabling the TaskBar extension also resolves laggy menus.

[phelps-sg]

Update

This also seems to be an issue with another extension: All windows. Could this be a bug in the Gnome extensions API? I am using Fedora 26 with Kernel 4.13.5-200.fc26.x86_64.

[phelps-sg]

Update

See this bugzilla report.

[stevenbell]

I've observed this bug as well. I'm on Ubuntu 17.10, Gnome 3.26.1.
I'm pretty sure this happens with both Wayland and X. This also seems to happen with right-click menus and Firefox tabs, not just app menus.

I'm happy to help debug, but I've never written GNOME extension code before and don't really know where to start. If someone can point me in the right direction, I'd be grateful.

[lsatenstein]

Steven.  Taskbar allows you to export and import settings. I am attaching my settings file. Enjoy. $HOME/taskbar.dconf [/] position-changed=false display-favorites-label='both' appearance-selection='tasks' dash=true position-max-right=4 display-inactive-tasks-frame-color=true system-menu-color='rgb(252,233,79)' tasks-label-color='rgb(138,226,52)' display-label='both' active-task-background-color-set=true extension-path='/usr/share/gnome-shell/extensions/TaskBar@zpydr' tasks-label='app' inactive-task-frame=true appview-button-icon='/usr/share/gnome-shell/extensions/TaskBar@zpydr/images/appview-button-default.svg' position-desktop-button=0 tasks-all-workspaces=true display-tasks-label-color=true active-task-background-color='rgba(0,0,0,0)' inactive-tasks-label-color='rgb(252,233,79)' position-favorites=2 position-tasks=4 tray-button-icon='/usr/share/gnome-shell/extensions/TaskBar@zpydr/images/bottom-panel-tray-button.svg' inactive-task-background-color='rgba(0,0,0,0)' hover-event=0 tasks-frame-color='rgb(239,41,41)' separator-right-appview=27 first-start=false application-menu=false workspace-selector=true position-appview-button=3 export-settings=true top-panel-original-background-color='rgba(0, 0, 0, 89)' display-inactive-tasks-label-color=true tasks-width=114 date-menu-color='rgb(252,233,79)' display-tasks-frame-color=true desktop-button-icon='/usr/share/gnome-shell/extensions/TaskBar@zpydr/images/desktop-button-default.png' inactive-task-background-color-set=true display-favorites=true bottom-panel-original-background-color='rgba(0, 0, 0, 89)' bottom-panel=true activities-button=true inactive-tasks-frame-color='rgb(239,41,41)' application-menu-color='rgb(138,226,52)' position-workspace-button=1 position-bottom-box=1 display-showapps-button=true   Regards  Leslie Leslie Satenstein Montréal Québec, Canada From: Steven Bell <[email protected]> I've observed this bug as well. I'm on Ubuntu 17.10, Gnome 3.26.1. I'm pretty sure this happens with both Wayland and X. This also seems to happen with right-click menus and Firefox tabs, not just app menus.I'm happy to help debug, but I've never written GNOME extension code before and don't really know where to start. If someone can point me in the right direction, I'd be grateful.— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[phelps-sg]

See also https://bugzilla.redhat.com/show_bug.cgi?id=1218402

[lsatenstein]

I am using Fedora 27, which has a most recent Gnome 3.26.1 (so I am told). Gnome Shell was the interface that constantly went into a loop with this extension, and with some other extensions.
However, when importing the tasbkar.dconf, See above, my listing of same, I experienced zero lockups or crashes. And thereafter, TaskBar works as one expects.

The issue is not TaskBar, it is with the Gnome Shell. Each later release of the Gnome Shell after 3.26.2 appears to be correcting bugs, simply because TaskBar is exercising Gnome shell functionality that was previously lacking adequate Quality Assurance Testing.

To import same, in your home directory, copy the above to taskbar.dconf
Start TaskBar and on the "About" tab, exercise the import option.

If you want proof that it is gnome-shell, enter terminal mode and issue the top command.
The first entry will likely be gnome-shell.
kill it, and performance should return to normal, as expected.

[zpydr]

Fixed in next release.

[stevenbell]

I've given v57 a try, and it seems to still have the lag problem. I completely removed the dconf entries for Taskbar, so I don't think it was an old configuration causing the problem.

One possibly-relevant bit of information is that the lag remains after I disable Taskbar until I restart gnome-shell.

How can I help debug this?