Inconsistent behavior between Windows (x64) and Linux (tar) regarding keyboard shortcuts

[tranquil-tr0]

Captchas

• [x] I have read the instructions.
• [ ] I have searched existing issues and avoided creating duplicates.
• [x] I am not filing an enhancement request.
• [x] I have checked that this issue cannot be reproduced on Mozilla Firefox.
• [x] I have checked that this issue can be reproduced once I removed all my Mods and Custom CSS.

What happened?

The behavior for keyboard shortcuts is inconsistent between platforms. I have duplicated #3031 which is my own issue, as I believe my explanation of the issue I was facing was not clear, since my understanding of web standards, which were the cited reason for closing the issue, do not cover this behavior. To enhance clarity, I have video-recorded with keystroke visualizer on both my Linux and Windows machine. Please correct me if I am wrong.

https://github.com/user-attachments/assets/b2f91920-40a8-41be-b11e-f3048cf20835

https://github.com/user-attachments/assets/d51755b7-c3af-4937-9a5f-5d3d28d9b3e6

Version

1.12.7b, 1.12.6b

What platform are you seeing the problem on?

Linux (Tarball), Windows - x64

What component is this issue related to?

Keyboard Shortcuts

Relevant log output if applicable

[0Ky]

I don't understand the issue here. Can you clarify and share the expected outcome?

a) with ctrl-alt-c ctrl-alt-v, the browser responded to the hotkeys while passing them to the site.

Just for reference, copying with Ctrl + C will copy the text with format too. You should preform your tests in https://w3c.github.io/uievents/tools/key-event-viewer.html. Also, it is technically possible for a website to capture a keyboard shortcut combination while the same keyboard shortcut combination is also used and processed by the browser at the same time. Here's a demonstration that shows pressing Ctrl+B, would make the text bold and at the same time shows bookmarks sidebar. If you don't want the browser to do anything when you press Ctrl+B, then you have to ask the web developer of the website to call preventDefault() during the event that's fired when the Ctrl+B keyboard shortcut combination is detected to prevent the default browser behavior.

This excludes those combinations which are strictly reserved by the browser engine. If you take a look at the dom/events/GlobalKeyListener.cpp file from the engine:

bool GlobalKeyListener::IsReservedKey(WidgetKeyboardEvent* aKeyEvent,
                                      KeyEventHandler* aHandler) {
  ReservedKey reserved = aHandler->GetIsReserved();
  // reserved="true" means that the key is always reserved. reserved="false"
  // means that the key is never reserved. Otherwise, we check site-specific
  // permissions.
  if (reserved == ReservedKey_False) {
    return false;
  }

  if (reserved != ReservedKey_True &&
      !nsContentUtils::ShouldBlockReservedKeys(aKeyEvent)) {
    return false;
  }

  // Okay, the key handler is reserved, but if the key combination is mapped to
  // an edit command or a selection navigation command, we should not treat it
  // as reserved since user wants to do the mapped thing(s) in editor.
  if (MOZ_UNLIKELY(!aKeyEvent->IsTrusted() || !aKeyEvent->mWidget)) {
    return true;
  }
  widget::InputContext inputContext = aKeyEvent->mWidget->GetInputContext();
  if (!inputContext.mIMEState.IsEditable()) {
    return true;
  }
  return MOZ_UNLIKELY(!aKeyEvent->IsEditCommandsInitialized(
             inputContext.GetNativeKeyBindingsType())) ||
         aKeyEvent
             ->EditCommandsConstRef(inputContext.GetNativeKeyBindingsType())
             .IsEmpty();
}

The engine intercepts specific keyboard shortcuts in the system marked as "reserved" before they reach the web content, which prevents the website from seeing or calling preventDefault() on these events.

That is why the following shortcuts cannot be intercepted/prevented within a website:

Ctrl+Tab (Switch to next tab)
Ctrl+Shift+Tab (Switch to previous tab)
Ctrl+T (New Tab)
Ctrl+N (New Window)
Ctrl+Shift+P (New Private Window)
Ctrl+W (Close Tab)
Alt+F4 (Close window)
Ctrl+Shift+Q (Exit browser)

[tranquil-tr0]

EDIT: Sorry, I noticed that my initial videos were the wrong ones. I have updated them now, and the videos should show a contrast that makes sense now. Hopefully that clarifies, since the wrong video obviously is very confusing.

I don't understand the issue here. Can you clarify and share the expected outcome?

Yeah, I was expecting that behavior would be consistent. Personally, I would prefer if both acted as linux (browser does not respond), but that isn't really relevant.

You should preform your tests in https://w3c.github.io/uievents/tools/key-event-viewer.html.

https://github.com/user-attachments/assets/722d84b4-2bd4-4466-95c9-8c3aaf7b4cc4

Also, it is technically possible for a website to capture a keyboard shortcut combination while the same keyboard shortcut combination is also used and processed by the browser at the same time. [...] If you don't want the browser to do anything when you press Ctrl+B, then you have to ask the web developer of the website to call preventDefault() during the event that's fired when the Ctrl+B keyboard shortcut combination is detected to prevent the default browser behavior.

Yes, however the demo is on the same website in the two initially given videos (the two operating systems), so while I don't know that much about google docs code, I can't imagine that the website detects OS and then decides not to call preventDefault() (also, just to make sure, even if I spoof my useragent on windows, it doesn't change behavior)

Here's a demonstration that shows pressing Ctrl+B

Yes, but in this demonstration website I can see that pressing ctrl+B will (summon bookmarks panel and bold) on both computers, however in the video it can be seen that pressing ctrl+alt+c (copies format and toggles compact) on windows while on linux it (copies format without toggling compact mode). Since the shortcuts, website, etc. are consistent, I would expect consistent behavior.

[0Ky]

So, this issue is about the behavior discrepancy between operating systems, where in Windows using a browser shortcut will register both in the website and the browser, but in Linux the shortcut is only registered in the website and not by the browser?

This is looking like an issue with the website (Google Docs), as confirmed by tests run by both of us in the Keyboard Event Viewer shows that the shortcut is registered in both the browser and website on both operating systems. If you block the "Override keyboard shortcuts" in the permissions for Google Docs, then it won't be able to prevent the default browser behavior and the Ctrl+Alt+C shortcut will work, but this will break the shortcuts provided by the website.

Here's a demonstration that shows pressing Ctrl+B, would make the text bold and ... shows bookmarks sidebar...

in this demonstration website I can see that pressing ctrl+B will (summon bookmarks panel and bold) on both computers

You just answered your own question here. Your issue is only with a particular website (Google Docs), therefore it isn't an issue with Zen browser.

[0Ky]

@tranquil-tr0 The same behavior you described can also be observed in Mozilla Firefox when using Google Docs. Simply switch to vertical tabs (on Firefox) and press the Ctrl + Alt + Z keyboard shortcut. On Windows, you'll notice that the accessibility menu option toggles in Google Docs while the browser simultaneously expands or collapses the vertical tabs. However, on Linux, the browser does nothing, but the website still toggles the accessibility menu option.

[dosubot[bot]]

Hi, @tranquil-tr0. I'm Dosu, and I'm helping the desktop team manage their backlog. I'm marking this issue as stale.

Issue Summary:

• Inconsistent keyboard shortcut behavior between Windows and Linux platforms in Google Docs.
• You provided video evidence showing differences: Windows affects both browser and website, Linux affects only the website.
• 0Ky suggested the issue might be due to the website's handling of shortcuts, not the browser.
• Similar behavior observed in Mozilla Firefox, indicating a potential need for website-specific adjustments.

Next Steps:

• Is this issue still relevant with the latest version of the desktop repository? If so, please comment to keep the discussion open.
• If there are no updates, the issue will be automatically closed in 7 days.

Thank you for your understanding and contribution!

[tranquil-tr0]

@tranquil-tr0 The same behavior you described can also be observed in Mozilla Firefox when using Google Docs. Simply switch to vertical tabs (on Firefox) and press the Ctrl + Alt + Z keyboard shortcut. On Windows, you'll notice that the accessibility menu option toggles in Google Docs while the browser simultaneously expands or collapses the vertical tabs. However, on Linux, the browser does nothing, but the website still toggles the accessibility menu option.

I see, apologies.

[dosubot[bot]]

Thank you for your detailed response, @tranquil-tr0! We appreciate your insights on the keyboard shortcut behavior across platforms. We'll be closing this issue now, but feel free to reach out if you have any more questions or concerns in the future!