Bug 185248 - [GTK] Special combination characters doesn't respect the keystroke order when high CPU load
Summary: [GTK] Special combination characters doesn't respect the keystroke order when...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Local Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-03 07:21 PDT by Andres Gomez Garcia
Modified: 2018-11-22 09:05 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andres Gomez Garcia 2018-05-03 07:21:01 PDT
I've been experiencing this for a long, loooong time. It only happens that I've finally decided to report this.

When using WKGTK+ (Ephy, as a ephy web app or embedded in, for example, Revolt (https://github.com/aperezdc/revolt) ), if the CPU gets to high load, usually due to WKGTK+ itself, writing in a text field doesn't get fluid. You may write a long text and it would only appear after some seconds.

When this happens, the keystrokes involving a combination of keystrokes, for example, accented letters (á, é, é, í, ó, ú) doesn't respect the order in which they were typed but jump to the first position.

For example, if I would be writing the following sentence:

"webkit está genial"

If the delay and high CPU happens just after the word "webkit" has been typed, I will get in the end:

"webkitá est genial"


I can reproduce this with Debian Testing's WebKitGTK+ 2.20.1 and Ephy 3.28.1

In any case, as said, I've experienced this for a long time.
Comment 1 Adrian Perez 2018-05-14 14:52:38 PDT
(In reply to Andres Gomez Garcia from comment #0)
> I've been experiencing this for a long, loooong time. It only happens that
> I've finally decided to report this.
> 
> [...]

I can confirm this, and I would be surprised if others who use
WebKitGTK+ based browsers/applications have not seen this as well.
It's been going on for a long time, indeed.
Comment 2 Adrian Perez 2018-09-17 02:23:51 PDT
Still happening with WebKitGTK+ 2.22.0
Comment 3 Claudio Saavedra 2018-11-22 09:05:03 PST
I found the culprit to this problem but I am not sure if the fix will be easy.

WebPageProxy, in the UI process, keeps a queue of keyboard events in order to send them to the Web process in order. It only sends one at the time, and the next in the queue is only sent when the web process responds that it has received the event (this is why under heavy load keystrokes are very slow, but that's a different issue).

For simple keys, the IM filter passes the event to the WebPageProxy, that queues the events as described above.

For composed keys, the IM filter passes the event to the WebPageProxy (which queues them), but in addition it handles the composition by using the composition methods. Once the composition is confirmed (say, á in example in comment #0), the WebPageProxy sends the ConfirmedComposition message to the web process with the composed text without regards to the key event queue, skipping it. The web process receives then the composed text and forwards it to the editor which inserts it immediately. The queued events in the ui process continue to be processed afterwards.