Nested GNOME shell cannot load example extension ("Extension ... does not exist")

[intgr (Marti Raudsepp)]

Hi! I tried following gjs.guide Getting Started | GNOME JavaScript to create a GNOME extension, but didn’t get farther from the first page.

I’m using GNOME Shell 45.1 on Arch Linux with Wayland.

I created the example extension with gnome-extensions create

% ls -la ~/.local/share/gnome-shell/extensions/example@gjs.guide
.rw-r--r-- 2,1k marti 25 Nov 15:32 extension.js
.rw-r--r--  122 marti 25 Nov 15:32 metadata.json
.rw-r--r--   45 marti 25 Nov 15:32 stylesheet.css

Then ran dbus-run-session -- gnome-shell --nested --wayland to create a nested GNOME session.

When I try to run any app from this session from the “Activities” app finder, it actually opens this application on my main desktop, not the nested window (?!)

I managed to hack around that issue by running WAYLAND_DISPLAY=wayland-1 alacritty, and got a terminal open in the nested session.

But still loading the example extension does not work, running the following in the nested Alacritty terminal:

% gnome-extensions enable example@gjs.guide
Extension “example@gjs.guide” does not exist

There are a lot of error and warning messages in dbus-run-session output. But nothing that sticks out as a smoking gun, I posted the log here: Output from nested GNOME session ($6292) · Snippets · GitLab

And I also tried searching the web for similar symptomps but did not find anyone else experiencing this.

[andyholmes]

@intgr

When I try to run any app from this session from the “Activities” app finder, it actually opens this application on my main desktop, not the nested window (?!)

A nested session doesn’t work like a virtual machine. The applications you launch will open as windows normally do.

Usually the workflow is to launch a terminal in the nested session, then run gnome-extensions enable. You can also use the GNOME Extensions app too, as long as you launch it from inside the nested session.

Any applications you launch will use the nested D-Bus session, so unless the application is using some other IPC mechanism, the windows that open are running in the nested session.

@intgr

I managed to hack around that issue by running WAYLAND_DISPLAY=wayland-1 alacritty, and got a terminal open in the nested session.

The gnome-extensions command is communicating with GNOME Shell over D-Bus not Wayland, so you need to run it in the nested D-Bus session. You could set this up to get the DBUS_SESSION_BUS_ADDRESS env variable and run it with that exported, but it’s usually easier just to launch a terminal from inside the nested session.

[fmuellner (Florian Müllner)]

@intgr

When I try to run any app from this session from the “Activities” app finder, it actually opens this application on my main desktop, not the nested window (?!)

This is an issue with D-Bus activated apps.

When mutter sets up the wayland display, it exports the WAYLAND_DISPLAY variable and communicates the value to gnome-session, which propagates it to the D-Bus daemon’s launch environment.

When running nested, gnome-session isn’t available on the session bus, so the display isn’t propagated to the D-Bus daemon.

@intgr

I managed to hack around that issue by running WAYLAND_DISPLAY=wayland-1 alacritty

Right, that works around that issue.

This is the relevant snippet from the wrapper script I usually use to run the shell:

display=wayland-$RANDOM
env WAYLAND_DISPLAY=$display dbus-run-session gnome-shell --wayland-display=$display --nested