Géza Búza

Hi @battosai30, Well I experienced similar random failures in the past, that's why I changed the code to retry the failed token refresh multiple times while there is an exponential...

Hi @uusijani @Pasquale95, I'm sorry, but Gnome Shell 3.32 introduced a change in the Javascript engine which seems to break backward compatibility. I don't have time and willpower to install...

As Gnome developers said, the Gnome Shell is single threaded, so you can't tell the memory usage of individual extensions externally (e.g. by `top` command). The extension reads various files...

There was a fault in the extension. I started to watch the `gnome-shell` process and I see that the used amount of RAM increases over time. So it looks like...

@CubeTheThird Can you tell which version of Gnome do you have? I did some experiment to find memory leaks in the extension code, but it seems like JS code itself...

There is a [discussion going on](https://gitlab.gnome.org/GNOME/gnome-shell/issues/64) about a Gnome Shell related bug. So far it confirmed my theory of something wrong with Javascript garbage collector.

Memory usage has been improved since [Gnome Shell 3.30](https://help.gnome.org/misc/release-notes/3.30/). @CubeTheThird Could you upgrade Gnome to 3.30.0 or later and do some testing to see if you still experience this problem?...

Hi @genodeftest, Thanks for reporting this bug. Updating the GUI happens asynchronously. When you lock your screen the extension will be disabled by Gnome and re-enabled after unocking the screen....

I'm afraid this still going to happen randomly. There is a technical difficulty as Javascript does not allow cancelling Promise chains (https://stackoverflow.com/questions/29478751/cancel-a-vanilla-ecmascript-6-promise-chain#29479435).

Hi @gerhas, I'm sorry to say that I can't do too much about it. The main problem is that Gnome Shell extensions are not running in separate threads, but shares...