Issue with WH_KEYBOARD_LL Hook and getUserMedia Interaction

[leeroy]

Despite using the default CEFClient and altering the `OnPreKeyEvent` of `client_handler.cc` as shown below, I observe the log entry '!!!!! WINDOWS PRE KEY PRESSED - BLOCKING'. However, the start menu still opens. Ultimately, my goal is to find a workaround for the issue described at https://github.com/chromiumembedded/cef/issues/2609, ideally without having to patch the Chromium source code and deal with the ensuing side effects..

Code: Select all

bool ClientHandler::OnPreKeyEvent(CefRefPtr<CefBrowser> browser,
                                  const CefKeyEvent& event,
                                  CefEventHandle os_event,
                                  bool* is_keyboard_shortcut) {
  CEF_REQUIRE_UI_THREAD();

  if (event.type == KEYEVENT_RAWKEYDOWN || event.type == KEYEVENT_KEYDOWN) {
    if (event.windows_key_code == VK_LWIN  || // 0x5B
        event.windows_key_code == VK_RWIN) { // 0x5C
      LOG(INFO) << "!!!!! WINDOWS PRE KEY PRESSED - BLOCKING";
      return true;
    }
  }

  LOG(INFO) << "!!!!! NON-WINDOWS PRE KEY PRESSED";

  return false;
}


Should this be filed as a bug with CEF?

[KatrinaS]

Since the gaffer hasn't replied to you regarding your is this a bug query I think you must just be missing a crucial piece of information, he's helping by making you rack your brain until you get that eureka moment Personally I wouldn't even bother trying to catch it in the deep dark depths of the C source, nah I'd try capturing / cancelling the specific keystrokes in any HTML Document its self

[leeroy]

Thanks KatrinaS! We attempted to capture key presses within the HTML document, but found that specific key combinations, including those involving the Windows key, are still triggering actions.

[KatrinaS]

Oh right,, I've got a Document in a CEF concoction right now, I'll see if it does the same for me

My conclusion,, the 'doze key is acted upon before anything else that cares to be listening (CEF, V8, everything) has a chance to cancel it

Apparently according to the Google oracle,, and it seems about right...

Essentially you install a low-level keyboard hook to eat the undesired keys. You also need to handle the WM_ACTIVATEAPP message to enable/disable the hook appropriately (otherwise you'll eat the keys when you're not the active application).

[leeroy]

We have decided to keep using a Low-Level Keyboard Hook (LLKH), but we've disabled Chromium's LLKH via a fork in CEF. Ideally, we would prefer not to maintain a separate fork and would like to utilize the OnPreKeyEvent feature. However, at this point, this approach appears to be the only viable solution.

[magreenblatt]

The CefKeyboardHandler::OnPreKeyEvent callback is for keyboard events that will be passed to the browser. Events handled by the OS (like Windows key), or events that arrive while the browser does not have keyboard focus, are not expected to reach this callback. If the Windows key reaches this callback it will be asynchronous with Windows handling the event (e.g. it can't block Windows from handling it).

[magreenblatt]

We have decided to keep using a Low-Level Keyboard Hook (LLKH)

I believe (and the internet appears to agree) that using a keyboard hook is the only way to capture the Windows key.

[leeroy]

We have decided to keep using a Low-Level Keyboard Hook (LLKH)

I believe (and the internet appears to agree) that using a keyboard hook is the only way to capture the Windows key.

I agree, this is certainly working. The idea of not having to update and maintain patches for Chromium, which is continually evolving, is quite appealing to me.

magreenblatt and KatrinaS thanks again for all your help with this!

[KatrinaS]

At least it should be a fairly static region of the codebase