265746 2023-12-03 00:36:00 -0800 [enhancement] use flatpak portal directly rather than using the flatpak-spawn executable 2024-08-25 00:36:35 -0700 1 1 1 Unclassified WebKit WebKitGTK Other Unspecified Linux NEW P2 Normal --- 1 two webkit-unassigned bugs-noreply mcatanzaro philn oldest_to_newest 1996530 0 two 2023-12-03 00:36:00 -0800 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 2054985 1 two 2024-08-23 13:32:05 -0700 (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 2055120 2 mcatanzaro 2024-08-24 06:21:39 -0700 (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. 2055192 3 two 2024-08-25 00:36:35 -0700 (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)