Feature #15828

Ensure users can enable GNOME Shell extensions on Wayland

Added by sajolida 2018-08-21 14:01:12 . Updated 2019-11-23 06:41:19 .

Status:
Rejected
Priority:
Normal
Assignee:
Category:
Target version:
Start date:
2018-08-21
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Additional Software Packages
Deliverable for:

Description

See Feature #8795#note-6:

Currently on Wayland there’s no way to restart GNOME Shell without restarting the full GNOME session, which we don’t support in Tails.

This might be a problem for:

  • Additional Software that run some stuff before GNOME Shell starts (e.g. parcimonie) or as part of GNOME Shell (e.g. GNOME Shell extensions). We don’t document how to do that currently but such cases might appear after Additional Software has been released officially. For example, I suffer from that with gnome-shell-pomodoro.
  • Anything else?

Subtasks


Related issues

Related to Tails - Bug #9059: "Additional software" locks the opening of the desktop Resolved 2015-03-15 2017-12-15

History

#1 Updated by intrigeri 2018-08-22 10:46:07

  • Subject changed from Impossible to restart GNOME Shell from a session in Wayland to Ensure users can enable GNOME Shell extensions on Wayland
  • Description updated
  • Type of work changed from Research to Test

I’m narrowing the scope of this ticket a bit (justifications below) so it tracks the only currently identified potential blocker, that we have a chance to fix, instead of a fundamental GNOME+Wayland design problem that we can’t realistically block on.

sajolida wrote:
> * Installing other GNOME Shell extensions in general. Does this make sense outside of Additional Software?

Yes, one can install extensions from https://extensions.gnome.org/ but I think we should not bother supporting that => removing it from the ticket description.

> At least I hope that Wayland will prevent GNOME Shell from crashing and restarting on its own (I still see this almost everyday) or otherwise we might have deeper problems…

It crashes because of an extension we’re shipping, which is incompatible with Wayland, so we’ll have to drop it, which should fix the crashes :)

Next step: test if gnome-shell-extension-tool --reload-extension=RELOAD + gnome-shell-extension-tool --enable-extension=ENABLE is enough to enable an extension without restarting GNOME Shell.

Worst case I have workarounds in mind that we could document in order to keep unofficially supporting this use case :)

#2 Updated by intrigeri 2018-08-22 10:46:55

  • Target version set to 2019

(Like the parent ticket.)

#3 Updated by intrigeri 2018-08-22 11:19:40

  • Assignee set to alant
  • Type of work changed from Test to Research

> Next step: test if gnome-shell-extension-tool --reload-extension=RELOAD + gnome-shell-extension-tool --enable-extension=ENABLE is enough to enable an extension without restarting GNOME Shell.

That does not work, which is not very surprising given how extensions work currently :( There’s talk in GNOME upstream about providing a more restricted API to extensions, which may fix this kind of problems, but even if this happens it’ll be in years.

So the only way to have additional extensions enabled on Wayland is:

  1. ensure the package is installed before GNOME Shell starts: that used to be the case but we’ve intentionally broke support for this category of ASP in order to fix Bug #9059, which was deemed more important than supporting this kind of ASP… but we did not take the GNOME Shell extension into account back then (or we did but did not write it up because we thought it was fixable just by restarting GNOME Shell, which is good enough as long as we don’t support GNOME Shell extensions officially)
  2. ensure the extension is enabled (gsettings) before GNOME Shell starts: I’m pretty sure that’s feasible with dotfiles but it’s not worth researching as long as we have no solution for the first problem

Alan, do you have any idea how to fix this fallout of Bug #9059?

sajolida, do you see this as a blocker to move to Wayland? On the one hand we’ve never supported this use case very nicely nor officially so I would say “no”. OTOH I don’t know how many users install GNOME Shell extensions via ASP so perhaps it’s worth computing stats so we base this decision on actual data.

#4 Updated by intrigeri 2018-08-22 11:19:49

  • related to Bug #9059: "Additional software" locks the opening of the desktop added

#5 Updated by intrigeri 2018-08-22 11:20:00

  • Affected tool set to Additional Software Packages

#6 Updated by alant 2018-12-16 19:24:15

  • Assignee changed from alant to sajolida

intrigeri wrote:
> Alan, do you have any idea how to fix this fallout of Bug #9059?
>
No, I don’t think this is possible. Either we wait for the ASP install and delay starting the shell or installing ASP shell extensions won’t work in the current state of the shell and ASP.

#7 Updated by sajolida 2019-06-03 17:09:39

  • Status changed from Confirmed to Rejected
  • Assignee deleted (sajolida)

#8 Updated by intrigeri 2019-11-23 06:41:19

>> Next step: test if gnome-shell-extension-tool --reload-extension=RELOAD + gnome-shell-extension-tool --enable-extension=ENABLE is enough to enable an extension without restarting GNOME Shell.

> That does not work, which is not very surprising given how extensions work currently :( There’s talk in GNOME upstream about providing a more restricted API to extensions, which may fix this kind of problems, but even if this happens it’ll be in years.

GNOME 3.34 brings a new way to enable/disable extensions. For example: gnome-extensions enable $UUID. It would be great to test whether that helps wrt. the problem at hand.