As it was brought up in the mailing list recently, there are some signals for which the default handlers in the WebView prevent them from being propagated as there is no way to know, in a multi-process model, when the WebProcess have actually processed them or not (they should be propagated when not processed). See more detailed explanation in .
Options proposed were, mainly, to either store the event in the UI process and re-emit later once we know the Web process has not been handled (as done for key events) or simply to return FALSE to always propagate them, which sounds like a good option for events like motion-event-notify, which do not act over any specific target (see  for a better explanation of the rationale behind).
I discussed this with Carlos on IRC and he agrees on doing that change for motion events, so tracking that change here.
Created attachment 268681 [details]
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Committed r194846: <http://trac.webkit.org/changeset/194846>