Supporting shortcut keys

[dreijer]

I'm adding keyboard shortcut keys to my browser. For instance, I'd like backspace to browse to the previous page, like most browsers do.

I'm using CEF3 in OSR-mode and am manually injecting the input to the browser instance. I'm not sure how to properly detect whether I should let the backspace event propagate or not. For instance, if the user has focused a textbox in the browser, I don't want to navigate to the previous page if the user hits backspace; on the other hand, if nothing on the page has the keyboard focus, I'd like to handle the key event myself.

[magreenblatt]

You can use CefKeyboardHandler::OnKeyEvent() which will only be called after WebKit has a chance to handle the key event. CefKeyEvent aslo has a |focus_on_editable_field| member that will be true if an editable field currently has focus.

[dreijer]

Poifect. Just what I needed!

[dreijer]

Follow-up questions:

The documentation for CefKeyboardHandler::OnKeyEvent says that "Return true if the keyboard event was handled or false otherwise". What does that mean? What will happen if I handle the event as opposed to not?

[magreenblatt]

Follow-up question:

The documentation for CefKeyboardHandler::OnKeyEvent says that "Return true if the keyboard event was handled or false otherwise". What does that mean? What will happen if I handle the event as opposed to not?

If you return false the key event will be forwarded to the platform for whatever purpose the platform desires (shortcut key handling, etc). See CefBrowserHostImpl::PlatformHandleKeyboardEvent() for the operating systems that you're interested in.

[dreijer]

Follow-up question:

The documentation for CefKeyboardHandler::OnKeyEvent says that "Return true if the keyboard event was handled or false otherwise". What does that mean? What will happen if I handle the event as opposed to not?

If you return false the key event will be forwarded to the platform for whatever purpose the platform desires (shortcut key handling, etc). See CefBrowserHostImpl::PlatformHandleKeyboardEvent() for the operating systems that you're interested in.

Alright, thanks.

Is there any way to get a focus changed event when a field actually gets focused in the browser? The problem I'm having is how the flow of input works in the GUI framework I'm using:

1. App generates input event
2. I inject the input in to CEF
3. I need to know at this point whether it's safe for me to let the event propagate to other controls in the application.

With CefKeyboardHandler::OnKeyEvent, I won't know whether the event went to a focused field or not until my input event handler has completed and I know longer have a way of letting the original event propagate. However, if CEF had already told me that a field was focused, then I could've done the right thing.

[magreenblatt]

Is there any way to get a focus changed event when a field actually gets focused in the browser?

Yes, see the example usage of OnFocusedNodeChanged in cefclient: https://code.google.com/p/chromiumembed ... nderer.cpp

[dreijer]

Yes, see the example usage of OnFocusedNodeChanged in cefclient: https://code.google.com/p/chromiumembed ... nderer.cpp

Ah! It looks like CEF already internally handles this event and ships it over to the browser process via the content::NOTIFICATION_FOCUS_CHANGED_IN_PAGE notification (unless I've misunderstood the quick glance of the code I took), so that it can update its focus_on_editable_field_.

Couldn't this be turned into an actual event that consumers of e.g. CefFocusHandler could handle?

[magreenblatt]

Yes, see the example usage of OnFocusedNodeChanged in cefclient: https://code.google.com/p/chromiumembed ... nderer.cpp

Ah! It looks like CEF already internally handles this event and ships it over to the browser process via the content::NOTIFICATION_FOCUS_CHANGED_IN_PAGE notification (unless I've misunderstood the quick glance of the code I took), so that it can update its focus_on_editable_field_.

Couldn't this be turned into an actual event that consumers of e.g. CefFocusHandler could handle?

OnFocusedNodeChanged is a more generic solution that provides a higher level of detail.

[dreijer]

OnFocusedNodeChanged is a more generic solution that provides a higher level of detail.

Sure, but you're already letting the client know about some part of focused editable fields (when keyboard input is happening), so why not cover the other end where the focus changes by a different means of input, such as the mouse? I mean, you're already handling this internally in the browser process and passing it on to the client "sometimes", so why not pass it on at other times. It sounds like a pretty ordinary use-case for the client wanting to know if the browser has focused an editable field or not.