Left Alt + space/shift expands the file menu but should do nothing.

[lampholder]

Rageshake report from a user who uses left alt + space to change keyboard layout but Riot electron catches that and opens the file menu.

User reports that it is more normal for left alt press-and-release to open the file menu, and for left alt + space to be unbound and uncaptured.

This is likely platform specific (Linux) - I think Windows left-alt-plus-space might usually be bound.

[t3chguy]

in Windows [l]Alt + Space opens the window management context menu, same as happens when you click the logo in top left of the window

[t3chguy]

Though I can not reproduce on my linux machine, [l]Alt + Space opens some search feature of KDE, so electron isn't catching it [l]Alt down and release shows the menu bar as expected.
Might need more information such as Distro and DE

[532910]

It was me.
It doesn't depend on WM, just on my xkb settings:

partial modifier_keys
xkb_symbols "alts-space-switch" {
	key <SPCE> {
		type = "MY_TYPE",
		symbols = [ space, ISO_First_Group, ISO_Last_Group ]
	};
};

[532910]

on my lalt-space xev shows:

KeyPress event, serial 39, synthetic NO, window 0x2a00001,
    root 0x4a8, subw 0x0, time 70841451, (93,37), root:(685,1278),
    state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 39, synthetic NO, window 0x2a00001,
    root 0x4a8, subw 0x0, time 70841867, (93,37), root:(685,1278),
    state 0x8, keycode 65 (keysym 0xfe0c, ISO_First_Group), same_screen YES,
    XKeysymToKeycode returns keycode: 62
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 39, synthetic NO, window 0x2a00001,
    root 0x4a8, subw 0x0, time 70842091, (93,37), root:(685,1278),
    state 0x8, keycode 65 (keysym 0xfe0c, ISO_First_Group), same_screen YES,
    XKeysymToKeycode returns keycode: 62
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 39, synthetic NO, window 0x2a00001,
    root 0x4a8, subw 0x0, time 70842459, (93,37), root:(685,1278),
    state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

[532910]

riot-web opens menu on the first "ISO_First_Group" in the sequence.

[VasoVV]

Why reference to element-hq/element-desktop#787 is here?

The reporter (and me too) is not downthumb on the menu bar that appears when Alt is pressed and released.
That is normal behavior e.g. in Firefox. But Firefox doesn't open this menu when any key strokes with Alt are using, as Element does.
That is the bug that makes Element-desktop absolutely unusable for people who use these combinations.
For example I using Alt+Shift to switch keyboard layouts. During texting I could switch languages several times and every time I have to fight with file menu, that always appears after Alt is released.

Time to time I've install Element-desktop, and remove it after 5 minutes of endless fighting with menu bar.

The "severity" of this bug rather blocking than minor.

Additional observation:
If pressing Alt+Shift in "pure" way (Press Alt than Shift, release Shift than Alt), the menu doesn't appear.
But usually nobody presses keys this way -- that is mechanically poorly action.
Alt is always released the last and toggle annoying menu bar in Element-desktop.

[t3chguy]

as Element does.

Do you have this issue with any other modern Electron apps? Element doesn't do have any explicit handling for Alt, its all boilerplate Electron.

[VasoVV]

I don't use any. But I've install typora for testing and have got the same behavior.

After some searching I've found that it is really an electron issue
And seems it wouldn't be resolve in the nearest future.

[532910]

Is this menu needed? What is it needed for?

modern Electron apps

Jitsi has no menu.
Drawio is completely unusable: menu is always visible, but it expands the only pane just by pressing (not releasing) alt-space (ISO_First_Group in my case)

[t3chguy]

The menu is required to bind to accelerators for simple key bindings whilst the window is in focus by the main process without external dependencies.

[xvenge00]

The issue is resolved in electron by PR. The fix is included in the latest release v12.0.11. So the bump in the should be sufficient. The patch is available in PR. It works for me on the element-desktop version 1.7.30, but i don't have time to check the develop branch.

[t3chguy]

Closing in favour of element-hq/element-desktop#787