spinning at 100% cpu, flickering mouse cursor

[richvdh]

Steps to reproduce

1. Hover over reaction/reply/thread/etc button
2. move mouse around a bit in this area

Outcome

icons and mouse cursor start flickering; display freezes.

https://user-images.githubusercontent.com/1389908/155000083-e9674609-7b6e-4813-bacb-9725098142b5.mp4

Only solution seems to be to quit and restart

Operating system

ubuntu 20.04

Application version

Element Nightly version: 2022021501 Olm version: 3.2.8

How did you install the app?

nightly debian

Homeserver

No response

Will you send logs?

Yes

[germain-gg]

Rageshake did not surface useful information unfortunately. Possibly related to https://github.com/vector-im/element-web/issues/21127

[richvdh]

I can reproduce it pretty reliably, fyi.

It has the air of one of those CSS bugs where:

• hovering over a thing makes it change state,
• which makes it get smaller
• which means you're not hovering over it any more
• which makes it get bigger

etc

[richvdh]

Turns out that if you leave it flickering for long enough without interacting with the window, it eventually recovers.

[richvdh]

this is a real show-stopper, hitting me multiple times a day. Is there anything I can do to help with a resolution?

[richvdh]

have switched back to the release version of element-desktop pending a fix here

[germain-gg]

Have not been able to reproduce this issue at all on Mac

[germain-gg]

The symptoms are very similar to what is described in https://github.com/vector-im/element-web/issues/20960

[richvdh]

Now that v1.10.5 (and v1.10.6) have been released, I'm also having this problem on the release version.

The symptoms are very similar to what is described in https://github.com/vector-im/element-web/issues/20960

Agreed. Was there a change of Electron version or something in v1.10.5 which might have brought this?

[germain-gg]

Just had a look, and Electron was upgrade to v17 when we released v1.10.5. Marking this issue as a regression. And it might be Electron specific

[richvdh]

I also see the problem on develop.element.io in Chrome (v99.0.4844.51)

So on the one hand, this does seem to be a problem in Chrome/Chromium, in that @grinapo observed it on other sites.

But Element must be doing something to trigger it somehow...

[r4dh4l]

Have exactly the same problem under Debian 10.11 with:

~# apt policy element-desktop
element-desktop:
  Installed: 1.10.6
  Candidate: 1.10.6
  Version table:
 *** 1.10.6 500
        500 https://packages.riot.im/debian buster/main amd64 Packages
        100 /var/lib/dpkg/status

[grinapo]

See also the chromium bug.

It seems to be triggered by javascript-heavy pages with cursor changes.

[richvdh]

I wonder if it would be possible to create a minimal reproduction case outside element-web, to help the chromium team debug it.

[JulianGro]

For anyone else on Ubuntu/Debian, you can downgrade to a usable version by installing https://packages.element.io/debian/pool/main/e/element-desktop/element-desktop_1.10.5_amd64.deb via dpkg -i package.deb

[r4dh4l]

For anyone else on Ubuntu/Debian, you can downgrade to a usable version by installing https://packages.element.io/debian/pool/main/e/element-desktop/element-desktop_1.10.5_amd64.deb via dpkg -i package.deb

Unfortunately I have the same "flickering problems" with 1.10.5 so currently I'm testing 1.10.4.

[richvdh]

according to https://bugs.chromium.org/p/chromium/issues/detail?id=1301067#c21, this will be fixed in Chrome 101.

[geckolinux]

I'm having major trouble with this in Element-Desktop on openSUSE Tumbleweed. Maybe there's a common thread between those of us who are experiencing the issue?

My main computer has hybrid/discreet graphics, but I don't use the Nvidia graphics nor do I install the proprietary drivers, so it's basically just a standard Intel UHD Graphics 630 system.

I also use a custom GTK theme based on Numix, which doesn't give me any trouble with other apps, but since this is a CSS bug it makes me wonder if there could be some quirk there?

This bug is currently happening to me on the Flatpak version of Element-Desktop (tried v1.10.8 and v1.10.7 and v1.10.6), but it was also happening in that same version range with the element-desktop packages from the openSUSE Tumbleweed repo and also from the taw00 Element RPM repo.

I rolled back to this version in the Flatpak repo, which definitely does not have this bug: Element version: 1.10.3 Olm version: 3.2.8

[richvdh]

https://bugs.chromium.org/p/chromium/issues/detail?id=1301067 suggests the common thread may be the window manager in use - users of xfwm4 and MATE have reported it.

(Element-web 1.10.4 is the last version before the switch to Electron v17, so is the last version without this bug.)

[geckolinux]

https://bugs.chromium.org/p/chromium/issues/detail?id=1301067 suggests the common thread may be the window manager in use - users of xfwm4 and MATE have reported it.

Hmm OK, FWIW I'm on the latest Cinnamon version, which internally implements libmuffin (so no separate WM process, it's wrapped into the cinnamon process), similar to metacity from Gnome.

[MountainX]

I reported it with KDE Plasma 5, Olm version: 3.2.8, electron17 17.4.0-1, Element 1.10.8-2 on Arch Linux.

[MountainX]

Turns out that if you leave it flickering for long enough without interacting with the window, it eventually recovers.

I have seen it recover after a while in some cases, but I was attempting to let it recover just now and it core dumped. I had opened it in a console, so I have that output:

$ /usr/lib/electron17/electron /usr/lib/element/app.asar
/home/user/.config/Element exists: yes
/home/user/.config/Riot exists: no
No update_base_url is defined: auto update is disabled
Fetching translation json for locale: en_EN
Changing application language to en-us
Fetching translation json for locale: en-us
Could not fetch translation json for locale: 'en-us' Error: Cannot find module './i18n/strings/en-us.json'
Require stack:
- /usr/lib/element/app.asar/lib/language-helper.js
- /usr/lib/element/app.asar/lib/tray.js
- /usr/lib/element/app.asar/lib/electron-main.js
- /usr/lib/electron17/resources/default_app.asar/main.js
- 
    at Module._resolveFilename (node:internal/modules/cjs/loader:940:15)
    at Function.n._resolveFilename (node:electron/js2c/browser_init:249:1105)
    at Module._load (node:internal/modules/cjs/loader:785:27)
    at Function.c._load (node:electron/js2c/asar_bundle:5:13343)
    at Module.require (node:internal/modules/cjs/loader:1012:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at AppLocalization.fetchTranslationJson (/usr/lib/element/app.asar/lib/language-helper.js:76:20)
    at /usr/lib/element/app.asar/lib/language-helper.js:89:39
    at Array.forEach (<anonymous>)
    at AppLocalization.setAppLocale (/usr/lib/element/app.asar/lib/language-helper.js:88:17) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/usr/lib/element/app.asar/lib/language-helper.js',
    '/usr/lib/element/app.asar/lib/tray.js',
    '/usr/lib/element/app.asar/lib/electron-main.js',
    '/usr/lib/electron17/resources/default_app.asar/main.js',
    undefined
  ]
}
Resetting the UI components after locale change
Resetting the UI components after locale change
[80201:0412/082559.040771:ERROR:vaapi_wrapper.cc(1096)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[80201:0412/082559.040944:ERROR:vaapi_wrapper.cc(1043)] FillProfileInfo_Locked failed for va_profile VAProfileH264Main and entrypoint VAEntrypointVLD
[80201:0412/082559.041017:ERROR:vaapi_wrapper.cc(1096)] vaQuerySurfaceAttributes failed, VA error: invalid parameter
[80201:0412/082559.041058:ERROR:vaapi_wrapper.cc(1043)] FillProfileInfo_Locked failed for va_profile VAProfileH264High and entrypoint VAEntrypointVLD
Changing application language to en-us
Fetching translation json for locale: en-us
Could not fetch translation json for locale: 'en-us' Error: Cannot find module './i18n/strings/en-us.json'
Require stack:
- /usr/lib/element/app.asar/lib/language-helper.js
- /usr/lib/element/app.asar/lib/tray.js
- /usr/lib/element/app.asar/lib/electron-main.js
- /usr/lib/electron17/resources/default_app.asar/main.js
- 
    at Module._resolveFilename (node:internal/modules/cjs/loader:940:15)
    at Function.n._resolveFilename (node:electron/js2c/browser_init:249:1105)
    at Module._load (node:internal/modules/cjs/loader:785:27)
    at Function.c._load (node:electron/js2c/asar_bundle:5:13343)
    at Module.require (node:internal/modules/cjs/loader:1012:19)
    at require (node:internal/modules/cjs/helpers:102:18)
    at AppLocalization.fetchTranslationJson (/usr/lib/element/app.asar/lib/language-helper.js:76:20)
    at /usr/lib/element/app.asar/lib/language-helper.js:89:39
    at Array.forEach (<anonymous>)
    at AppLocalization.setAppLocale (/usr/lib/element/app.asar/lib/language-helper.js:88:17) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
    '/usr/lib/element/app.asar/lib/language-helper.js',
    '/usr/lib/element/app.asar/lib/tray.js',
    '/usr/lib/element/app.asar/lib/electron-main.js',
    '/usr/lib/electron17/resources/default_app.asar/main.js',
    undefined
  ]
}
Resetting the UI components after locale change
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
<repeats the above line hundreds of times>
libpng warning: iCCP: known incorrect sRGB profile
kf.service.services: KApplicationTrader: mimeType "x-scheme-handler/file" not found
kf.service.services: KApplicationTrader: mimeType "x-scheme-handler/file" not found
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true
libpng warning: iCCP: known incorrect sRGB profile
<repeats the above line many more times>
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Trace/breakpoint trap (core dumped)

The last line happened while this issue was in progress. I was not (could not) use Element, so I was just letting it sit there to see if it recovered.

[sumnerevans]

FWIW, I've observed this on i3wm as well. How long does it normally take for the change in Chromium to trickle its way up through electron to us?

[t3chguy]

Will be fixed by Electron 19 (Currently in Alpha) which upgrades to Chromium 102

[grinapo]

From the chromium issue... FYI

Hm.. yeah it appears it may not have been merged in time for the M101 cut. M102 will have the fix for sure. You can use the beta channel in the meantime if you like.

[MountainX]

Leaving this comment here in case it helps any other users. I suspect it won't be of help to the developers, and I apologize for this.

Background: I have been using Element extensively for work and personal communications for years. I have literally forced all my family, friends and work associates both inside and outside our company to use it. It's been a great tool. I don't know of any alternative I would be satisfied with. But this last month has been painful due to these two issues:

1. Element crashes within 5 minutes (or less) when message search is enabled (which I was told is related to https://github.com/vector-im/element-desktop/issues/691). I've been keeping message search turned off, which is not ideal.

2. This issue vector-im/element-web#21147. This was causing multiple "crashes" per day where Element would become unresponsive. I would either have to force terminate the app, or wait up to half hour (which would usually end with a crash, but would sometimes recover). Every single day this would happen between 3 and 6+ times.

Two days ago I replaced Element Desktop with SchildiChat Desktop version: 1.10.4-sc.1 and so far I have not experienced either issue mentioned above, even with message search enabled. I'm not sure how or why because it uses the same version of Electron that causes the problems on Element (and I assume the codebase is nearly identical). But I'm now back to my previous great level of usability with full functionality.

SchildiChat has all the features of Element, so this has been a good solution for me. Maybe this will help others until this issue is fixed. I don't know of another workaround that would be this seamless for using the desktop version. I hope this post is not inappropriate here. I'll remove it if requested.

[JokerGermany]

have this problem several times a day, too. Had this with Ubuntu Mate 20.04 and have this with Ubuntu Mate 22.04

[robintown]

Electron 19 is scheduled to be released on May 24, so this should be fixed in 3 releases' time (June 7, barring any complications).

[MountainX]

have this problem several times a day, too.

If you check this issue: https://github.com/vector-im/element-web/issues/22038, the following comment might help you until Electron 19 is out.

Also: in the tray, I am and to reset the mouse to working if I do a "show/hide" cycle to bring the window back up.

I can't verify that because I switched to SchildiChat and I have not had the issue anymore after that switch. However, the "show/hide" cycle seems like an easy temporary workaround, if it works for you.

[JokerGermany]

have this problem several times a day, too.

If you check this issue: vector-im/element-web#22038, the following comment might help you until Electron 19 is out.

Since i use Ubuntu Mate 22.04 he is freezing even harder. It's not only the window, it's the tray, too. Then sometimes Ubuntu Mate 22.04 tells me that element isn't reacting anymore.

[PF4Public]

Just a heads-up. I can confirm that this issue is fixed in Chromium-102.

[PF4Public]

I have rebuilt element-desktop with electron-19 and can no longer reproduce this issue:

https://user-images.githubusercontent.com/10319700/170561269-9c2c9837-7fbb-4e60-a4ae-1a29b7f896da.mp4

If there are other ways of reproducing it I'd gladly test them too.

[IF-Adin]

This bug sadly makes the element desktop app unusable for me in Linux. It happens all the time. Is this planned for the next update? Seems like Electron 19 works?

[t3chguy]

@IF-Adin Electron 19 released a week ago, we have not yet updated to it and the RC for the next release was cut. It will likely make it for the release after

[IF-Adin]

@t3chguy Thank you.

In the meantime, could we maybe have instructions for a workaround? Do you recommend downgrading? Being without my primary means of communications is not great.

At the moment, i've hacked Firefox to hide it's address bar and all that, it kind of works. No search though.

[t3chguy]

If https://github.com/vector-im/element-desktop/pull/372 gets approval and passes CI then Element Nightly will be built off Electron 19, that'd be the recommended workaround.

[IF-Adin]

@t3chguy Understood, thank you for the help.

[geckolinux]

In the meantime, could we maybe have instructions for a workaround? Do you recommend downgrading?

@IF-Adin What I did was downgrade to Element 1.10.3 with Flatpak. (General instructions here: https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks#downgrading)

[IF-Adin]

Can confirm bug is no longer present in the nightly.

[rom4nik]

Unfortunately I'm still experiencing this, albeit far less often on Element v1.10.15.

[robintown]

@rom4nik 1.10.15 was a hotfix release targeting other, unrelated bugs, and as such it does not yet include the fix for this issue. The next non-hotfix release will.

[geckolinux]

So I imagine that the v1.11.0 release that was just announced should contain the fix?

[t3chguy]

@geckolinux Yes