Bug 265746 – [enhancement] use flatpak portal directly rather than using the flatpak-spawn executable

• Status: NEW
• Component: WebKitGTK

flatpaked browsers have process trees looking like this:
```
| epiphany
|| flatpak-spawn
|| flatpak-spawn
|| ...
```

afaik all those flatpak-spawn are doing are telling a portal to spawn a process in a different sandbox then waiting for a d-bus notification for its end. using the flatpak-spawn executable probably adds up to the tab startup time, and can fail due to bugs such as https://github.com/flatpak/flatpak/issues/5398, making epiphany stuck in an infinite loop. this would probably be better done in the browser process.

but that would probably be difficult to implement, since it's async and also the processes are in a different PID namespace, so they have to be killed via the portal too

(In reply to two from comment #0)
> but that would probably be difficult to implement, since it's async and also
> the processes are in a different PID namespace, so they have to be killed
> via the portal too

*it uses --share-pids already to have a common pidns, so not as much as i thought needs to be changed

[Michael Catanzaro]

(In reply to two from comment #1)
> *it uses --share-pids already to have a common pidns, so not as much as i
> thought needs to be changed

No, there is no common pid namespace.

It does use --expose-pids, but that is different. There's still separate pid namespaces.

Ultimately flatpak-spawn is just a convenience wrapper around the portal API. If we stop using it, we're probably just going to have to wind up reimplementing whatever else it is doing, so there should be a good reason for doing so.

(In reply to Michael Catanzaro from comment #2)
> so there should be a good reason
> for doing so.

most importantly to work around the "Invalid byte sequence in conversion input" bug... but now i looked at flaptak-spawn's code again, and i think it might also be fixed by passing /proc/self/environ to --env-fd instead of passing each variable to --env?

but also to shorten the current micro freeze when spawning a new web process by not having to wait for pidSocket

(also because less processes)