[Webkit-unassigned] [Bug 136430] [GTK] Key press signal fired twice in WebKit2

[bugzilla-daemon at webkit.org]

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

Michael Gratton <mike at vee.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike at vee.net

--- Comment #4 from Michael Gratton <mike at vee.net> ---
This the underlying cause of this has been causing problems with the WK2 port of Geary.

We historically have used a number of single keystroke shortcuts, and to ensure they weren't triggered when composing a message, we had effectively had to override gtk_window_key_press_event() since that (1) checks for keyboard shortcuts to activate (by calling gtk_window_activate_key) before (2) sending the event to the focus widget (by calling gtk_window_propagate_key_event). The overridden implementation simply calls gtk_window_propagate_key_event first, then chains up, so gtk_window_propagate_key_event ends up being called twice if the event is not handled before then.

So when a WebView is focused and does not handle the event, the first call to gtk_window_propagate_key_event forwards the event on to WebView, which hands it off to the WebProcess and responds as if it had been handled, and no further processing occurs. The WebView generates a new event when it is notified by the WebProcess that the key event was unhandled, and forwards the event through the same machinery. The first call is not handled by the WebView (I'm not sure why, maybe WK2 has some special code to detect this and avoid re-handling the same event?), but the second call to gtk_window_propagate_key_event causes the same event to be sent to the WebView, which treats it as a new event and the whole thing then repeats. This chain effectively forms a busy-wait loop - the Gtk main loop machinery processes it all as fast as it can. Although the application remains responsive since it's an async process, the CPU will be pinned at 100%. Additional unhanded key strokes form additional cha

This happens for any keystroke sent to a WebView being used to display a HTML document, or when a keystroke like Shift is not handled when a TEXTAREA or content-editable region.

I guess this is a corner case, but took a while to work out what was going on. It would be nice if the underlying issue was documented somewhere, but I wonder if the events that the WebView re-injects after getting the async response back from the WebProcess could be flagged somehow as being the case, so applications could look out for them and operate on them or ignore them as appropriate. Could GdkEventKey somehow be extended, or maybe GdkEventKey::send_event be set to true?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170105/4469f8b3/attachment.html>