QtWebengine rendering sometimes freezes under EXWM

[Ambrevar]

I initially reported the issue on EXWM's issue tracker but since only QtWebengine seems to be concerned, I thought this might be a good place to investigate too.

Using EXWM, when I close a buffer (Emacs buffer or Qutebrowser popup), if the replacement buffer is a Qutebrowser window, sometimes the rendering of the webpage freezes, i.e. typing does not show, scrolling does not scroll, GIFs & videos are frozen.
As soon as I change Emacs windows configuration (e.g. enlarge or split the window), the rendering resumes.
The input works while the rendering was frozen, i.e. everything I have typed has actually had an effect.

I'm not experiencing high CPU usage.

OS: Gentoo, Arch Linux
GPU: Intel Xeon E3-1200 (Gentoo), Intel GM45 Express (Arch)
Xorg: 1.19.2 (Gentoo), 1.19.3 (Arch)
Emacs: GNU Emacs 25.2.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.16) of 2017-09-02
EXWM: 0.15
Qutebrowser: 0.11...1.0.2

Any lead?

[The-Compiler]

This seems similar to #2131, which was fixed for most (but not all?) people with Qt 5.7.1.

[Ambrevar]

I run Qt 5.7.1 on Gentoo and Qt 5.9.2 on Arch. Looks like it was half-solved, and that the symptoms have slightly evolved.

Thank you for the link, that was very helpful to help me understand it has to do with input fields!
The bug is very similar but with some differences: it also occurs when not in insert mode.

Best way to reproduce: straight from start page, duckduckgo! It freezes systematically. Now I know how to reproduce:

• The element under focus must be a text field, insert mode or not, and in the screen space, so it must be rendered.

• Sometimes (not sure what triggers this precisely), after defocusing the text field and focusing on another element, the issue still occurs if the aforementioned text field is in the screen space.
  The issue goes once the I scroll away enough so that the text field does not get rendered anymore.

• Pressing "o" does not unfreeze the rendering.

[The-Compiler]

I'm guessing you get the same issue with e.g. a 2.x QupZilla as well?

[Ambrevar]

Indeed!

[The-Compiler]

This kind of thing was supposed to be fixed in Qt 5.7.1: bug, fix. Since you can still reproduce it reliably, I'd encourage you to open a Qt bug about it.

As this doesn't seem like something qutebrowser can do anything (or work around), I'm closing this now.

[Ambrevar]

Reported upstream: https://bugreports.qt.io/browse/QTBUG-64029

[Ambrevar]

It seems that the issue is gone since early December on Arch Linux. Maybe something got fixed in Qt 5.10?