Esse efeito é devido a uma captura no X Windows . Quando eu executo um desktop Wayland no Fedora 25, até mesmo aplicativos X dentro do XWayland não têm mais esse efeito. Um bug do KDE relevante para este problema foi fechado em favor do uso do Wayland.
Tecnicamente, se uma captura é usada ou não, depende do kit de ferramentas da GUI / widgets usados (ou do aplicativo, se ele fala diretamente com o X). Muitos toolkits GUI usam um X grab quando um menu está aberto. No entanto, a razão para isso - e como o Firefox parece evitá-lo - parece ser bastante obscura.
Outro uso de X grabs é para jogos e áreas de trabalho aninhadas (por exemplo, acesso remoto e máquinas virtuais). Quando esta resposta foi originalmente escrita, Wayland não suportou nenhum método para obter os eventos de teclado que eles precisavam. [1] [2] . Portanto, não ficou claro exatamente como as tomadas XWayland seriam tratadas, ou seja, se o XWayland vai começar a ter o efeito específico que você descreve mais uma vez. Testar no Fedora 27 sugere que não.
StackOverflow sugere que usar uma captura de entrada, em vez de definir o foco de entrada para uma janela filho, pode ser a única maneira de impedir que os gerenciadores de janelas redesenhem a barra de título da janela principal na cor "inativa".
As fontes mais "oficiais" que consegui encontrar são relatórios de bugs. Está claro que o uso de X grabs para menus tem sido um problema de longa data. Se você ler até o final, verá uma sugestão que funciona em torno do problema do gerenciador de janelas acima. Talvez seja isso que o Firefox fez.
(pensando nisso, não tenho certeza se os atalhos de teclado globais eram tão significativos nos ambientes de desktop originais. Eu sei que Alt + Tab vem do CDE, mas não há razão óbvia para usar Alt + Tab enquanto um menu está aberto ).
The mechanism provided by X11 to implement popup menus is the global keyboard and mouse grab. All modern applications and toolkits use this mechansim, Qt included. Unfortunately, I don't see a way that this can be changed without some very serious behavioral changes (which will harm the user experience as well).
tela não bloqueia quando algum menu está aberto
this is answered by Michel in http://bugs.debian.org/514036
--8<-- Michel Dänzer
It does; it's the only way the menu can receive input events while the pointer is outside of it. AFAIK this is a pretty deep X11 design issue, so I'm afraid this can't be fixed easily. Feel free to bring it up upstream though.
--8<--
OK. thx for this information. I reported it to upstream:
I'm not clear that there is definitely a need for a keyboard grab to implement menus with access keys, even though that is what toolkits often do.
It may be convenient from the perspective that events are directed to the menu window.
But in most cases the main application window would have focus and so the application can receive keyboard events there.
If for some reason a client does not normally receive focus in the main window, I wonder whether it should negotiate keyboard focus (perhaps under the Globally Active Input model) rather than stealing a keyboard grab, which cannot be overridden until the client releases.
Um ponteiro pode ser útil para "clicar" no menu, clicando em qualquer outro lugar na tela, mas sem realmente acionar o elemento em que você clicou. No entanto Wikipedia diz que é possível pegar o ponteiro sem pegar o teclado ./