Describe the problem you’re having:

During keypress events the metakey is not taken into account.

This appears to be an issue only with Safari on macOS for some key combos using the command key and maybe with the Windows key on Windows machines with Chrome.

Testing with, Safari 14.0 (15610.1.23, 15610) on macOS 10.15.6 when using command-shift-n or command-z keyeventToAction from js/App.js will process this event as if you hit ‘n’ or ‘z’. I don’t believe that’s the expected action? I see similar results with the Windows key (metakey on Windows) and Chrome 85.0.4183.83. Hitting windows-z will act as if ‘z’ was pressed.

Looking at the keyeventToAction function in the browser’s javascript debugger during these events you can see even.metakey is true but metakey is only processed during a keydown event so the event continues as if it was a single character not “%key”

Adding: if (event.metaKey) hotkey_name = "%" + hotkey_name;
Maybe removing it from the keydown if block too?)
after the if (event.type == "keydown") ... else ... block seems to fix the issue. However, I don’t know the fallout for other functionality or other browsers.

	...
	if (event.type == "keydown") {
		hotkey_name = "(" + keycode + ")";

		// ensure ^*char notation
		if (event.shiftKey) hotkey_name = "*" + hotkey_name;
		if (event.ctrlKey) hotkey_name = "^" + hotkey_name;
		if (event.altKey) hotkey_name = "+" + hotkey_name;
	} else {
		hotkey_name = keychar ? keychar : "(" + keycode + ")";
	}

	if (event.metaKey) hotkey_name = "%" + hotkey_name;
    ...

If possible include steps to reproduce the problem:

Using macOS and Safari:

  • login in ttrss instance with Safari on macOS
  • Hit command-shift-n
  • If n is bound in ttrss see the ‘n’ keybind is executed or see in the debugger attempts to resolve the ‘n’ keybind.
  • I would expect this to try to resolve ‘%n’

If using Window/Chrome:

  • loing to ttrss
  • Hit Window-z
  • If z is bound in ttrss see the ‘z’ keybind is executed or see in the debugger attempts to resolve the ‘z’ keybind.
  • I would expect this to try to resolve ‘%z’

tt-rss version (including git commit id):
2b50aaed6

Platform (i.e. Linux distro, PHP, PostgreSQL, etc) versions:

macOS Client: macOS 10.15.6 (19G2021), Safari 14.0 (15610.1.23, 15610)
Windows Client: Windows 10 19041.450, Chrome 85.0.4183.83

Server: FreeBSD 12.1 amd64, php 7.2.33, postgres 11.9

i’m not interested in implementing any changes because of macs, os x, or safari.

on windows win key is normally reserved for the system, so trying to trap it might not be a good idea, if it is even allowed (in my personal opinion it probably shouldn’t be, if it is).

e: also this whole “i was removing this and that and it kinda works now maybe and idk about other platforms” thing :face_with_raised_eyebrow: .

So if metakey is true always return undefined?

the way it’s done now is that metakey is handled like everything else, if it doesn’t work properly i.e. requires special hacks, i think its on browser developers to make it work like altkey and the rest of them. i would prefer to not add special hacks because of this one thing.

in general i would prefer to keep things as is unless someone using a platform i can actually test things on complains and its actually application code being responsible.

alternatively we can remove metakey altogether, no stock hotkeys map to it anyway, it’s not big loss.

I would be in favor of this but if not I can just patch locally to fix this.

Also, something to keep in mind is that keypress is deprecated. Some of the hot key code might break at any time.

poor non-latin layout users

https://git.tt-rss.org/fox/tt-rss/pulls/110