GNOME Might Need To Crack Down On Their JavaScript Extensions

[discordian]

I had a bug recently with stuttering videos on Youtube.
I finally found it was caused by Gnome Shell extentions polling files to get temperature data, and other kind of stuff.
Because extensions are running in the same thread than the compositer, it's causing frame drops when performing too much I/O.
Clearly this is a design flaw, that needs to be addressed.

Yeah this drove me nuts for a while until I found the reason. I had a even worse issue enabling the "Places" extension, plug in an USB and crash (https://bugzilla.redhat.com/show_bug.cgi?id=1538493).

For all its faults, if you look at Windows: a crash in the desktop UI will not kill any of your running Apps. Proper separation.
There should be nothing but a list of rendering commands (as data-structure) processed by the global Desktop-session.

[Candy]

I finally found it was caused by Gnome Shell extentions polling [...] data, and other kind of stuff.

Not that you ended up installing some Extension that in reality did some bitcoin or etherium mining on your computer

[kpedersen]

And it cannot run separate sessions in separate nspawn/lxd/docker containers because of... oh, wait, I don't remember such limitation of Wayland protocol

Are you really saying that something like Windows 95 is a multi-user system because you can run multiple instances in a VM or container? That is what it is sounding like to me :/

[Delgarde]

I wonder why they considered implementing Javascript in the first place.

The reasons are discussed in a post linked to the article, but the short version is that they needed a language suitable for embedded use, that didn't come with its own platform to conflict with the Gnome one, and which was reasonably widely used. Javascript – especially 2009-era Javascript – is a pig of a language, but it met all the criteria.

And hindsight suggests that they made the right choice, since for all its flaws, for all the dislike, Javascript has gone on to become one of the most heavily used languages in existence. Their mistake wasn't the choice of language – it was the decision to run everything in a single unrestricted process, instead of providing isolation, and limited APIs.

Why didn't they use something like WebAssembly?

Um, because WebAssembly has been around since 2017, and development on Shell started in about 2009? But it may well be possible to use WASM for Gnome extensions... I've never looked into it, but the underlying JS engine presumably supports it.

[Tomin]

It is closer than you think. For VNC or RDP to work with proper sessions they each create a server (Xvnc, Xrdp respectively) which the X11 toolkits then connect to. These multiple servers running is what allows multiple clients to each have a separate session. What we have with wayland is more akin to the desktop in Windows 95 where as well as being crashed by a single application, it also cannot support multiple users on the same box.

What do you mean by "cannot support multiple users on the same box"? Sure you can do that with Wayland. On my computer gdm is on the first virtual terminal, my session is on the second and any new session started by gdm would be on the third (and so on). I can just swap between them with Ctrl+Alt+F-keys if I want to. With X it works the same way.

[Delgarde]

The big one for me *is* that it is too closely bound to the applications. Causing an application to be able to take it out (Mutter, Gnome 3, Bubba's Cheeky Script, etc...).

That's not a problem with Wayland as such... that's a problem with individual desktop implementations. Gnome Shell runs too much in a single process, so if interaction with applications triggers a bug, it takes down the compositor, and that takes down everything else. They seriously need to split that up a bit, try to pull stuff out of that critical compositor process... make it so crashes in the compositor are rare, and crashes in the rest can be recovered...

Besides, you could do that on X11 too... a WM crash wouldn't kill the xserver as such, but it could still take out all the processes launched by the WM. You could design the WM to avoid that, but a number of them ran panels and menus in the same process, and if they crashed, you'd be dumped back to the login...

[cybertraveler]

The blog post Michael linked is really concise, logical and clear. I recommend you read it if you haven't already:

https://eischmann.wordpress.com/2018/07/31/story-of-gnome-shell-extensions/

[discordian]

The blog post Michael linked is really concise, logical and clear. I recommend you read it if you haven't already:
https://eischmann.wordpress.com/2018...ll-extensions/

Yeah "looked like a good idea" to someone, very concise, logical and clear. Sorry, but that problems had been known for a long time, you need to coalesce drawing in one thread for performance (single rendering context, no locking) and you only do thing you can verify to not do random things (ie dont run client code, just client data).

java-script applets would not be the problem, letting them directly draw is.

[Sniperfox47]

Call me crazy but isn't a rewrite into a Gnome 4 almost due anyways? There have been massive changes to programming best practices and low level APIs since 2009.

If you're going to put in the effort to decouple shell from mutter (which seems like a neccessity), why not put the resources into modernizing the whole thing? Design it from the ground up for Wayland, to split up and isolate Compositor parts like Mutter, shell and extensions into their own processes, use a WASM backed API for extensions, and if they want to be ambitious build a next-gen shell using a PBR engine for drawing on top of Vulkan similar to what Fuschia is planning.

I'm not a gnome dev so I'm not really one to talk, but it seems kinda silly to keep putting Band-Aids on top of Band-Aids.

[onicsis]

The problem it's not javascript per se, but the fault is somewhat distributed. An unstable(or not so stable) Gnome Shell introduced a new and untested type (for the Desktop Environment) of extension , meaning 2xsources of incertitude.