Does onUnhandledInputEvent get called?

It's expected behaviour in WebView that all input events are swallowed, emitted into the DOM, and then propagated back to the embedding app via onUnhandledInputEvent if the DOM isn't interested in consuming them. Unfortunately this is the best we can do, because Android input processing is synchronous but web input processing is asynchronous.

If the input event comes back out that way, then this is working as intended unfortunately. If it doesn't, then that's an actual bug.

In the WebViewClient the onUnhandledInputEvent isn't being called, so if that's expected to be invoked then there is a bug with that functionality.

If that method was being called would that allow the Android ScrollView to scroll? Touch events don't have the same issue as mousewheel events, although I would assume that they would both behave in a similar way.

I've updated and attached the test app to add logging for the WebViewClient onUnhandledInputEvent.

Deleted: WebviewMouseScroll.tar.gz 21.0 MB

WebviewMouseScroll.tar.gz 21.0 MB Download

If the input event is being consumed by webview and not re-emitted into onUnhandledInputEvent then yes, that's a bug and we need to investigate.

If that was working, it would *still* not allow the ScrollView to scroll automatically. The app would have to actually do something to redispatch the input event to the appropriate place. The only place where the right thing can happen automatically is in the framework itself by WebView choosing not to consume the event when it's originally dispatched, and that's impossible because WebView is not able to determine whether it wants to consume the event synchronously. :(

> If the input event is being consumed by webview and not re-emitted into onUnhandledInputEvent then yes, that's a bug and we need to investigate. 

Wait, why? Surely webview should consume some events :p

Scroll in particular is weird, because it's *always* possible (I think) to consume the event in webview, even if webview doesn't scroll; it just gets bubbled up as overscroll in that case.

Webview itself is a scrollable container, and in general, it's a bad idea to put a scrallable container inside another scrollable container. I believe apps that have done this do gesture detection *before* sending the input events down to webview. Like torne said above, you have to do extra work either way to make it work.

Oh, right, in this case it's probably an overscoll instead and we should be consuming it. Sorry.

Thanks for all the quick replies.

Are touch events considered a special case even though the WebView is consuming them, because touching on the webview and moving it's still possible to scroll the ScrollView. Which isn't the case with the mouse cursor and the scrollwheel.

No idea. There is too much guessing work going on here.

Would it be appropriate to handle this in the Java android.webkit.WebView classes onGenericMotionEvent() method. So when an action_scroll occurs check using canScrolVertically()/canScrollHorizontally() if scrolling in the mouse wheel direction isn't possible return false instead of the actual return value. Or maybe just always return false when performing an action_scroll?

> Would it be appropriate to handle this in the Java android.webkit.WebView classes onGenericMotionEvent() method. So when an action_scroll occurs check using canScrolVertically()/canScrollHorizontally() if scrolling in the mouse wheel direction isn't possible return false instead of the actual return value.

You are just restating the "gesture detection *before* sending the input events down to webview" idea. If you want to do that in the embedding app, then that's fine.

> Or maybe just always return false when performing an action_scroll?

No. Then you can get double scrolls.

Also onUnhandledInputEvent has *never* been implemented in webview.

I was thinking a bit if it's possible to implement it, and I concluded it's not really possible or useful.

It's not possible because in general, events are transformed multiple times before webview knows it's unhandled, eg touch events are transformed into gestures, which might be transformed to key events etc. So by the time webview realizes an event is not parsed, the original event data is probably long lost.

It's not useful for apps either because even if it worked, what apps get back from onUnhandledInputEvent is a *partial* input stream, and that's pretty much useless. Eg, imagine only getting back touch move, but not touch down or touch up events. What could app possibly do anything useful with that *without* also looking at the input stream before webview gets it? And if app looks at the input before handing off to webview, then well, why is onUnhandledInputEvent useful at all?


We should definitely stop telling developers to use onUnhandledInputEvent, and maybe deprecate it too.

Ah. Sorry, I read our docs and assumed they were reasonable :(

onUnhandledInputEvent will be deprecated.

There are a few things I think that may help:
first is gesture detection before sending the input event down to webview (mentioned in #9)
second is listening to overscrolled event on webview, and figure out how much webview has overscrolled, then scroll the ScrollView accordingly (done by the app itself). This has to be done by the app because it is reasonable for webview to consume all the scroll events, even with overscrolls (webview is just gonna draw some overscroll glows in that case).

The only way to do this reliably to intercept input events *before* it enters webview.

There is no plan to improve this in anyway in webview at least.