[Webkit-unassigned] [Bug 64790] [GTK][WK2] Handle doneWithKeyEvent in GTK port

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jul 25 23:43:35 PDT 2011


https://bugs.webkit.org/show_bug.cgi?id=64790





--- Comment #19 from Carlos Garcia Campos <cgarcia at igalia.com>  2011-07-25 23:43:35 PST ---
(In reply to comment #17)
> (From update of attachment 101854 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=101854&action=review
> 
> I'm a bit concerned about the interaction of key release and following key press events.
> 
> 
> With the way the code is written now, what happens when this is called on a key release event? Won't this setting then effect the behavior of the next key press?

shouldForwardKeyboardEvent is set to false in both key press and release event handlers, so it won't affect any other events.

> > -
> > -    return GTK_WIDGET_CLASS(webkit_web_view_base_parent_class)->key_press_event(widget, event);
> > +    return TRUE;
> 
> I should clarify my confusion here. I do not understand how priv->shouldForwardKeyboardEvent can be true when webkitWebViewBaseKeyPressEvent is called. The only way I can see this happening is if during a previous key release event, priv->shouldForwardKeyboardEvent was set to true. I do not think previous key release events should affect future key press events (see my comment above).

shouldForwardKeyboardEvent is only true when a key press/release event is not handled by the web process, in this case we simply take the same event and send it to gtk to be processed again. Then key_press or key_release will be called, and shouldForwardKeyboardEvent will be true, so the handler will send the event to the parent widget and will set shouldForwardKeyboardEvent to false again so it won't affect future events. It's not a previous event, we are processing the same event again, so other key events are not affected.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list