Deliver input events that aren't consumed by a renderer back to the webview

Just pushed an implementation for the method HandleKeyboardEvent to the WebContentsDelegate. The method is converting the NativeWebKeyboardEvent back to a QKeyEvent. But there is two issues on the current implementation.

The first problem is how to retrieve back the key() from the original QEvent since the NativeWebKeyboardEvent stores only the nativeVirtualKey().

The other point is how to add the new QEvent to the queue of events to be processed.

To answer the second question: see QCoreApplication::postEvent(…) (http://qt-project.org/doc/qt-5/qcoreapplication.html#postEvent).

For the first issue, have a look at QKeyEventKeyCodeToWebEventKeyCode(…) in qt/core/browser/oxide_qt_render_widget_host_view.cc, this is where the QEvent’s key code is translated into the NativeWebKeyboardEvent’s windowsKeyCode, so you should be able to do the reverse translation.

Note that from a very quick look at your branch, you’re not actually overriding WebContentsDelegate::HandleKeyboardEvent(…) (see https://code.google.com/p/chromium/codesearch#chromium/src/content/public/browser/web_contents_delegate.h&q=HandleKeyboardEvent&sq=package:chromium&l=252).

I just updated the branch following your instructions. I am having some problems testing webbrowser-app with my own oxide build (even with out any change). Could someone take a review of this branch?

I tested the branch, I had to modify the target of QCoreApplication::sendEvent to be QGuiApplication::focusObject() for anything to go through.

However, with this change, any key press event enters an infinite loop where oxide::qt::WebView::HandleKeyboardEvent(…) generates a new QKeyEvent that is being handled by oxide::qt::RenderWidgetHostView::HandleKeyEvent(…), which forwards it to the renderer, which in turn will end up calling HandleKeyboardEvent…

Unless I missed something obvious from the proposed solution, this is not going to work.

A side note: once we figure out a working solution, it will be a good candidate for a unit test, QtQuick’s TestCase allows simulating keyboard events (see qt-project.org/doc/qt-5/qml-qttest-testcase.html#simulating-keyboard-and-mouse-events).

I'm just building this branch to investigate, but I'd expect the infinite loop when using QGuiApplication::focusObject() (assuming that the focus hasn't changed from the RenderViewItem). The event needs to be delivered to the WebView instead, and it's odd why this doesn't work. I'll take a look to try and figure out why.

As for unit tests - we could actually do with unit tests covering input event handing in general (for mouse, touch and keys). It's something where we're currently lacking quite a bit

Ok, I think I understand now:

First of all - we probably want to dispatch the returned event synchronously rather than posting an event to the event loop. So, sendEvent() would be more appropriate than postEvent(). Although, that's not the issue at play here.

When doing either QCoreApplication::postEvent() or QCoreApplication::sendEvent(), this is delegated to a virtual function - QCoreApplication::notify(), which is implemented by QGuiApplication. In the case here, we literally just dispatch the event to the webview, and leave it at that.

The mechanism for propagating events to parent widgets is actually implemented in QApplication::notify(), and we don't have one of those. To dispatch an event in QtQuick that propagates through to parent items, you need to use QQuickWindow::sendEvent():

http://qt-project.org/doc/qt-5/qquickwindow.html#sendEvent.

So, I think we need to delegate the dispatching of the QKeyEvent to WebViewAdapter, and do this call in OxideQQuickWebViewPrivate

One other thing - I'm not sure whether it would be worthwhile reimplementing content::NativeWebKeyboardEvent by omitting native_web_keyboard_event_aura.cc from the build and providing our own. It's not a lot of code, and it has a pointer (os_event) on which to store the original event. That might save some effort recreating it here.

You don't have to do that though :)