UI hangs several seconds, regulary

[madduck]

Steps to reproduce

Randomly, when trying to use Element-Web, I find that the UI stops responding for a few seconds at a time. When such is the case, character input isn't shown (but buffered, and after a few seconds, it'll appear in the input box). Also, interaction with other UI elements, such as context menus on individual posts, or the room list, isn't possible (no hover effects, and clicks don't have an immediate effect).

Outcome

It's quite hard to reproduce this in a meaningful way for this bug report, but I managed to capture a profile for the Firefox Profiler, and there you can see screenshots, as well as UI and network activity. I've put the profile up for download here

Check out this screenshot for now:

You can clearly see that everything seems to be blocking on a number of network requests, and in fact, it is during these two seconds that the UI wasn't responsive. So while the UI should never block on network, it does appear as if it does in this case.

Operating system

Debian Linux (unstable)

Browser information

Firefox 108

URL for webapp

develop.element.io and app.element.io

Application version

Both app and develop are affected:

• Element version: 85e2f06-react-b81582d04569-js-aead401005fa
• Element version: 1.11.17

Homeserver

matrix.madduck.net, Synapse 1.74.0

Will you send logs?

No

[germain-gg]

The profiler does highlight anything too useful on the JS side.
We have blocking operation on the message composer (related to message encryption, when hitting the send button) and other bits with the TimelinePanel (about ~1.2s)

It seems that the Layout operation and the renderer are having a hard time with this setup for some reason

[madduck]

I don't think anymore it's network related. Instead, I found out about "Jank, event processing delays", which coincide exactly with the UI problems. It seems to suggest that the main loop is busy and blocks:

Here is the profiler data. The problem is at the end of the recording:
https://scratch.madduck.net/2023-01-11-FF108_profile.json.gz

[madduck]

Just letting you know that the problem exists with app.element.io as well.

[madduck]

Honestly, this is becoming a show-stopper, and I've now seen it happen to others. It also drives energy consumption of Firefox when idle, which is really not good. Should I stop using Element?

[t3chguy]

Looks like 86% of the load was in the Composer, so this is likely to be changed by the new WYSIWYG composer in labs. Also worth noting that at times in the profile your moz extensions hit nearly 50% usage, so likely with a clean browser profile the hanging would not occur.

[madduck]

With the WYSIWYG composer, are you suggesting the Rich Text replacement for Markdown? I find it very difficult to wrap my head around the idea that a Rich Text Composer would solve a performance problem sid to exist with a Markdown text area, but I've been wrong before ;) Regarding my moz extensions hitting 50% usage — that's really interesting. Could you show me how you found that out? Is there a specific extension that sticks out? Feel free to email me at madduck ät madduck dot net.

…

-- The sender e-mail address used ***@***.***) is valid, and specific to our correspondence. It should not indicate any affiliation with your organisation. Die verwendete E-mail-Adresse ***@***.***) ist gültig und spezifisch für unsere Korrespondenz. Sie soll in keiner Weise auf eine Verbindung mit Ihrer Organisation hindeuten. Spamtrap: ***@***.***

[t3chguy]

With the WYSIWYG composer, are you suggesting the Rich Text
replacement for Markdown? I find it very difficult to wrap my head
around the idea that a Rich Text Composer would solve a performance
problem sid to exist with a Markdown text area, but I've been wrong
before ;)

The WYSIWYG composer supports markdown also. It is a ground up rewrite including the majority in Rust. Both Rust and ground up rewrites tend to be good for performance.