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.
(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.
Still happening with WebKitGTK+ 2.22.0
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.