Yes, exactly. David
-----Message d'origine----- De : directfb-dev-boun...@directfb.org [mailto:directfb-dev-boun...@directfb.org] De la part de Denis Oliver Kropp Envoyé : mardi 15 mars 2011 16:55 À : directfb-dev@directfb.org Objet : Re: [directfb-dev] [WebKitDFB] Request to allow a box to cancel window event propagation in Lite 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 _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
