File open/save dialogs show $SNAP_USER_DATA instead of $HOME when selecting the home shortcut

[oSoMoN]

(initially reported on launchpad: https://launchpad.net/bugs/1798450)

[kenvandine]

I've spent some time investigating this. I don't think it's a bookmark, it's literally using $HOME. In the snap's context, $HOME is $SNAP_USER_DATA. Maybe @oSoMoN can figure something out.

[oSoMoN]

To be exact, the GtkFileChooserWidget implementation uses g_get_home_dir(), which uses $HOME.
Changing the value of $HOME would have undesirable side effects.

Reading the actual implementation of g_get_home_dir though, it checks $G_HOME first. So maybe we could set that variable accordingly to achieve a sane default for the home folder in the file save/open dialog?

We need to be careful with this approach though, because this means any code that calls g_get_home_dir() will get the path to the real home directory, not the confined one.

[oSoMoN]

I tested setting $G_HOME to /home/$USER with the libreoffice snap, and I can confirm that the file open/save dialog now has a sane default for the home directory.

However there are a number of places in gtk that call g_get_home_dir(), so it might not be such a good idea to override its return value unconditionally. On top of that, gtk applications might call that function directly and expect to get the confined path (~/snap/<appname>/<revision>/) to function properly (libreoffice doesn't, nor does it test the value of $G_HOME).

So at best this trick could be used with selected applications, carefully tested to ensure this doesn't introduce subtle side effects. The LibreOffice snap might be a good candidate.

[seb128]

That's only for snaps getting access to the real userdir right? (so we would have to make that variable conditional on the interface to be connected)
Also I'm unsure that problem is really specific to the file chooser or to desktop applications, it's rather about deciding what's the right default place to store/access user data no? (or do we want to store e.g files & config in the private dir but let the user browse the shared one?)

[seb128]

oh, also ~/.

are not allowed by default, changing what the glib function returns might lead to have apps trying to write their config in a location they are not allowed to use

[oSoMoN]

I think that's rather specific to desktop applications (connected to the home interface), and only for user-generated files (where to save them by default, or where to open previously saved files).
Configuration files should remain in the confined location.

[didrocks]

Exactly, as Seb wrote, this is the tricky part.
In generally, it makes sense for those snaps to get access to user's home for storing/dealing with apps.
However, there is the issue with ~/.*.

I think snaps using the gtk filechooser portal won't be impacted, as the portal can expose the real user home directory and be aware of that, while still have the HOME set to the SNAP_HOME directory, and thus, not having the permission issue we talked about.
Do we have a list of apps using snapcraft-desktop-helpers which can't benefit from the file opener portal? (I guess, listing themselves in their UI the directory tree structure and such…)