Alt-<number> passes onto the web page unintended during tab switch
The Alt-<number> keyboard shortcut is used to switch between tabs. However, the key event used to switch a tab seems to also propagate down to the content itself. This creates weird interactions:
- I switch to third tab - The web page running in the third tab actually uses Alt-3 to do something - After switching tabs the web page does something unexpected because the browser chrome didn't swallow the event during its tab-switching procedure.
The most irritating candidate seems to be XenForo forum software that uses Alt-<number> to go to different sections in its menubar. For example, alt-4 seems to open a search page and going there provides no new entry in the browser history. So, if I've tab-opened the forum to display new posts and then later I switch to it using Alt-4, it makes the content go to its search panel with no way to go back to new posts. Ironically, switching _away_ from the tab 4 does not register to the content so I can't even use the forum's own keyboard shortcuts to navigate back to new posts section or any other section. Having the forum in tab X will only ever let the forum see Alt-X and nothing else.
This all stems from the fact that Firefox lets the initial tab-switching key event through whereas I think it shouldn't. It maybe should if the corresponding tab is already active but it certainly shouldn't when a tab-switch actually occurs.
I've obviously disabled the content's capability to override keyboard shortcuts but it doesn't help in this because the content is not overriding anything: it seems to be just listening to a keyboard event that it shouldn't see.
Did I miss some option in about:config or do others see this as well?
所有回覆 (1)
Hmmmh… tricky question. I don't think it's deliberate, but equally I'm not sure this is handled intentionally in a consistent fashion.
On macOS 15 this doesn't seem to reproduce, CMD+2ing to a tab with keyboard event echo it doesn't seem to receive the input — however… in my case, when I have such tab active in an inactive window #1, and close last tab of windows #2 above it using CMD+W, I see both the modifier and the letter keys as pressed in the tab that's about to become the frontmost now. Trying to reproduce again I'm not successful, using e.g. https://w3c.github.io/uievents/tools/key-event-viewer.html I only see the modifier key up, in some attempts I see the letter "w" key up, but not consistently — so not sure this is designed to work in a certain way.
I however see "action" events properly swallowed, on CMD+T, CMD+Tab, CMD+Shift+Tab around this verbose debug page only the modifiers are logged, but the actual letter not — so whenever a command is recognized, it seems exposing that key event to the content is not favorable. Might be worth filing a bug to see if that's Linux–specific, or some input method–specific, and not as expected in general.