GNOME Bugzilla – Bug 719468
All the top bar menus open after keyboard navigation
Last modified: 2021-07-05 14:07:11 UTC
Steps to recreate the bug: Open any application. Ctrl+Alt+Tab and select top bar to switch to navigation on top bar. Press the right arrow so app menu will be selected. Press down to open app menu. After that press right to switch to time, again to right for language, all the way till the end to status area. Go back pressing left arrow couple of time all the way to Activities, and finally again go back to the right. All the App menu and time and language selector and status area will remain open at the same time
Created attachment 262999 [details] Bug Screenshot
Hi Denis. I've tried reproducing your bug, but am unable to. I don't have the input sources menu open though - maybe that has something to do with it? Pro tip: try and give your bug titles specific comments! :)
Created attachment 263089 [details] Top Bar Bug Clocks
(In reply to comment #2) > Hi Denis. I've tried reproducing your bug, but am unable to. I don't have the > input sources menu open though - maybe that has something to do with it? Not sure if this is the issue. I run Gnome Shell 3.10.2.1 on Fedora 20 x64. Tried the bug with Evince, Clocks..same story > Pro tip: try and give your bug titles specific comments! :) I Will =)
Yikes. This one is a can of worms. I'm able to reproduce. It only happens with apps that have app menus. I'll look at providing a fix soon.
Created attachment 263475 [details] [review] panel: Properly fizzle out re-setting the menu to the same app Ever since the RemoteMenu rewrite, actionGroup has been private, meaning that we never fizzled out setting the app menu to the same thing when we didn't need to. This means that when updating the menu, we reset the menu. If we reset the menu at some unfortunate times, like when the menu was opening, then various bugs could happen where the menu we were opening was swapped out from under our feet, getting various components confused. Add public API to compare whether a RemoteMenu is for a specific action group and menu model, and fizzle out where appropriate.
Created attachment 263476 [details] [review] Add an API to get the default window for the screen / workspace Even when windows do not have key focus, we might want to know what window would get the key focus.
Created attachment 263477 [details] [review] panel: Look at the app for the default window when no window has focus Previously, we played tricks by trying our hardest not to sync when the panel didn't have key focus, but that's not really an approachable situation anymore. Use new mutter APIs to look up the default window and look at the app for that when we're key-nav'd to the panel.
OK, so now for the long explanation: this happens because the menu gets rebuilt and re-set when we're trying to switch from another menu to it. This happens because when we're switching from another app to it, the grab modal grab on the last menu drops, just for a tiny bit, enough to re-focus the default window and change the key focus to NULL. Which means that our code to fizzle out the change in focusAppChanged doesn't work, so we try and re-set the menu, and we end up setting the menu to a dummy menu, which we then attempt to re-grab. It also didn't help that the check for making sure we don't recreate the same menu again was broken, meaning that menus were probably being recreated all over the place. So now we have two grabs: one for the original menu, and one for the dummy. The tracking now in PopupMenuManager is hella confused, and has *no* idea what's going on, and that's why you get the many menus problem. Fun. I'm attempting to solve this by making focus-app fall back to the app for the default window (the window that we would focus otherwise, when we drop our modal grab). Perhaps there's a better way to solve this, though.
Tested the bug on 3.15.90 Still the bug persists
Created attachment 299048 [details] The bug in 3.15.90
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.