Portal dialog opens in background, unseen by user

[BillDietrich]

I've seen this in multiple apps, but the most prominent offender that comes to my mind is VS Codium. When using Flatpak of the app, and portals, I click on "Open", and nothing happens. After 10 seconds, I realize that the file-open portal dialog has opened in the background, and I have to Alt+Tab to make it visible.

Before you say this is an app bug, go file against the app, I've seen it in multiple apps and distros and DEs, which leads me to think perhaps the portal specification or guidance or API maybe is lacking in this area. Is there a way for an app to force focus to shift to the portal dialog ? Is this advertised to app developers ? Today the UX of using portals in some apps is a bad experience because of this issue. What can be done to improve it ? Thanks.

[BillDietrich]

Note: similar happens with a "pick what application to use to open this type of file" dialog. I tell app to open a file such as a PDF, it pops up the "which app ?" portal dialog in the background, I see it as "app did nothing". 15 seconds later, I realize I have to Alt+Tab to go find the portal dialog.

[BillDietrich]

Another note: this is an intermittent problem. Sometimes the dialog appears in foreground as expected. Sometimes not.

[jadahl]

What DE is this for? The portal backend is responsible for the dialogs, and they tend to use different methods for get correct stacking of dialogs. The way it works is roughly this:

1. The portal using application exports a "handle" for its toplevel window (using xdg-foreign in Wayland) and the window XID in X11
2. The portal using application passes this handle via the portal API (it's usually parent_window in the API)
3. The portal forwards this information to the backend
4. The portal backend makes use of this information to tell the compositor / window manager to stack things correctly

If the application doesn't create and provide the handle, the application must be fixed.

How the 4th step works depends on the portal backend, which tends to depend on what DE you're using.

[ssokolow]

...and I can personally attest to focus-stealing prevention and window stacking behaviour being buggy in the version of KDE used in Kubuntu Linux 20.04 LTS, Flatpak portals or not.

jadahl's explanation almost certainly boils down to one of two things in the context of your Electron example:

1. VSCodium (or possibly the version of Electron used, depending the API) isn't passing the parent_window argument when invoking GtkFileChooserNative, giving the window manager's focus-stealing prevention perfectly good grounds to assume the dialog is an attempt at focus-stealing by an unrelated application.
2. There's a bug in the window manager or the portion of the portal host that's written by your chosen desktop environment that's causing it to not properly apply what the common portal host code told it.

In either case, this wouldn't be the place to report the bug and the workaround would be to reconfigure your window mananager (eg. turn down focus-stealing prevention, add something to KWin's Window Rules dialog to exempt or force-focus portal dialogs, etc.)

[jadahl]

For the case where parent_window isn't passed, I don't think we pass around any activation tokens that can make focus stealing prevention work (i.e. allow stealing here), unless we explicitly plumb the token from the applications. But that means the applications needs to pass along this information.

[BillDietrich]

What DE is this for?

I've seen this in Ubuntu Unity 22.10, ZorinOS, and Fedora Kinoite (KDE) at least.

[ssokolow]

I've seen this in Ubuntu Unity 22.10, ZorinOS, and Fedora Kinoite (KDE) at least.

Then it's likely that VSCodium isn't telling the OS which window the dialog is parented to, and I suspect it worked before because of ugly hacks involving something like whether the two windows originate in the same X11 socket as a proxy for whether they originate from the same process.

(Bearing in mind that Qt applications and, in GTK 4, GTK application using the even newer file dialog API they're working on, will use the file chooser portal when present, regardless of Flatpakking in order to get DE-native file choosers, and that some applications may open more than one X11 connection if, for example, the author wanted to use XGrabKey and didn't know how to get xlib-python running on top of the X socket GTK or Qt opens. Both of which will break any old "dialog originated from the same X socket" hacks.)

[BillDietrich]

This happens in more apps than just VS Codium.

[GeorgesStavracas]

@jadahl I can't think of anything in particular that can be done on xdg-desktop-portal side to remedy this issue. I acknowledge this is a problem though.