On 03/15/2011 04:44 PM, david.corvoys...@orange-ftgroup.com wrote:
Hi,
The current Window event handling chain in Lite allows the main application to
have callbacks being called before and after a specific box has handled an event
(For the sake of simplicity I will only focus on keyboard events, but the same
applies to mouse events).
Typically, you can define a keyboard event handler for a specific box:
box.onKeyDown = event_cb
And you can also use the following code to be called before and after a
keyboard event has been processed by the box:
lite_on_raw_window_keyboard( window, before_event_cb, user_data );
lite_on_window_keyboard( window, after_event_cb, user_data );
Now, only the first callback to be called has in fact the ability to stop the
event to be passed to other handlers by returning DFB_FAILURE (the return values
of other CBs are simply ignored, as you can see in window.c).
Thanks for pointing out.
This is an issue for WebKitDFB:
The WebKitDFB library displays pages in boxes, and a specific keyboard handler
is defined for each box. This handler calls in turn the page keyboard event
handler in WebCore.
According to the standard, any web page displayed by a browser should have the
ability to prevent it from performing any default action by calling
evt.preventDefault() on the captured DOM event.
The simplest implementation of the preventDefault behaviour is to test the
return value of the page event handler and return DFB_FAILURE if
evt.preventDefault()
has been called (in that case the WebCore function returns true).
Now, what happens if the main application using the library has defined an
"after_event_cb" using lite_on_window_keyboard to perform extra actions after
the
event has been handled by the page (like activate scrolling if up/down has been
pressed) ?
Since the return value of the box event callback is never tested, the
after_event_cb will always be called (and the preventDefault flag is thus
ignored). And
this is _bad_ ...
I would therefore suggest an evolution to Lite to actually test the return value of the
box event cb, and only call the "after" handler if the result is DFB_OK
(just like it is done for the "raw" event cb).
What do you think ?
The following should be changed to only call the window->keyboard_func if ret
is DFB_OK, true?
case DWET_KEYDOWN:
ret = handle_key_down(window, event);
if(window->keyboard_func && !(window->flags &
LITE_WINDOW_DESTROYED))
window->keyboard_func(event, window->keyboard_data);
break;
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
