Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
G
gnome-shell
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,262
    • Issues 1,262
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 106
    • Merge Requests 106
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GNOME
  • gnome-shell
  • Issues
  • #2689

Closed
Open
Opened Apr 25, 2020 by Florian Müllner@fmuellnerMaintainer

Extension installation?

The Extensions app handles extension configuration, updates and removal, but not installation. That is in line with the design outlined in #1968 (closed), which keeps the website/web-extension in charge of that.

Unfortunately that's not the end of the story.

It turns out that the host integration works by registering a binary with the browser, which it then launches as necessary and communicates with the process via stdout. Which is extremely sandboxing-unfriendly to say the least:

  • setting it up with the minimal permissions is incredibly cumbersome
  • the alternative of registering a script that does flatpak-spawn --host chrome-gnome-shell is slightly less cumbersome, but requires permission to run random programs on the host (not great for browsers!)

This is a problem for all web exensions that use native messaging, so there's some pressure to come up with a sandboxable replacement. Maybe that means we can just wait it out 🤷

But I don't like standing in the way of flatpak adoption, in particular for browsers where sandboxing is particularly desirable.

Off-hand I see two options around the issue:

  • change the website to drop the whole plugin/management stuff and expose simple "Install" buttons that use something like gnome-extension:foobar@extensions.example.com, then have a simple schema handler that translates that to the corresponding D-Bus call

    Compelling from a gnome-shell perspective, as most of the work would be on the website; but it's somewhat less nice (the site no longer knows whether an extension is already installed or not), and the change would either render the web extension obsolete (probably not popular with its developers) or make the website more complex if implementating the change as fallback when the plugin/connector aren't available or fail

  • add extension browsing/search/installation in the Extensions app

    Probably more appealing for users, but a big increase of the app scope.

Thoughts?

@aday

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: GNOME/gnome-shell#2689