[Bug]: nosocket=fallback-x11 clears out an explicitly given socket=x11

[refi64]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.
• If this is an issue with a particular app, I have tried filing it in the appropriate issue tracker for the app (e.g. under https://github.com/flathub/) and determined that it is an issue with Flatpak itself.
• This issue is not a report of a security vulnerability (see here if you need to report a security issue).

Flatpak version

1.15.6, master

What Linux distribution are you using?

Fedora Linux

Linux distribution version

39

What architecture are you using?

aarch64

How to reproduce

1. Run a Flatpak with the arguments --socket=x11 --nosocket=fallback-x11.

Expected Behavior

The X11 socket is exposed into the app.

Actual Behavior

This does not happen:

$ flatpak run --socket=x11 --nosocket=fallback-x11 --command=env org.freedesktop.Platform//23.08 | rg DISPLAY
GNOME_SETUP_DISPLAY=:1
WAYLAND_DISPLAY=wayland-0

However, it works if I swap the arguments:

$ flatpak run --nosocket=fallback-x11 --socket=x11 --command=env org.freedesktop.Platform//23.08 | rg DISPLAY
DISPLAY=:0
GNOME_SETUP_DISPLAY=:1
WAYLAND_DISPLAY=wayland-0

Additional Information

No response

[smcv]

Run a Flatpak with the arguments --socket=x11 --nosocket=fallback-x11

Why would you do this? The best description I can see of the semantics of those options is something like this:

"Run my app, and give it access to my X11 socket, but if you're unable to connect to my Wayland socket, don't fall back to giving it access to my X11 socket"

... and I'm having a hard time seeing how that could be a useful thing to represent!

[smcv]

The important use-case for combining --socket=x11 and --nosocket=fallback-x11 is that if they happen at different levels of precedence, they should combine in the way that a user would expect (whatever that might mean).

When I say "levels of precedence", I mean things like: flatpak run > flatpak override --user > sudo flatpak override --system > app metadata.

[refi64]

... and I'm having a hard time seeing how that could be a useful thing to represent!

For some more context: I was running an app that had --socket=fallback-x11, and I wanted to make it just --socket=x11, and also it was past 6pm at which point I really should not be trying to figure things out? But I do think the UX is a tad confusing: all the other permissions afaik work such that allowing and toggling them only toggle that one, so a tired brain going "I must turn off the existing one and turn on the new one" kinda makes sense, even if it's silly in retrospect.

That being said it's probably still not worth supporting...but I do wonder if combining --socket=fallback-x11 and --socket=x11 at any point should show a warning? This example would've triggered that since the --socket=x11 was run while --socket=fallback-x11 was still active, and it would make it clear "this does what makes sense but it may not be what you are, at this moment, expecting".