"Save As" dialogue default path NullReferenceException

[Dylan Gundlach]

Version: 2.1.1
OS: Ubuntu 20.04.6 LTS

reproduce:
open pinta
File=>Save As
    set name: some-new-image.jpg
    the path will default to something like /run/user/1000/doc/95720e22
    hit Save
exception window appears: "Unhandled exception":
    System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.NullReferenceException: Object reference not set to an instance of an object.
   at Pinta.Actions.SaveDocumentImplmentationAction.SaveFileAs(Document document)
   at Pinta.Actions.SaveDocumentImplmentationAction.Activated(Object sender, DocumentCancelEventArgs e)
   at Pinta.Core.FileActions.RaiseSaveDocument(Document document, Boolean saveAs)
   at Pinta.Core.Document.Save(Boolean saveAs)
   at Pinta.Actions.SaveDocumentAsAction.Activated(Object sender, EventArgs e)
   at Pinta.Core.Command.<.ctor>b__33_0(Object o, ActivatedArgs args)
   at InvokeStub_ActivatedHandler.Invoke(Object, Object, IntPtr*)
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)
   --- End of inner exception stack trace ---
   at System.Reflection.MethodInvoker.Invoke(Object obj, IntPtr* args, BindingFlags invokeAttr)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Delegate.DynamicInvokeImpl(Object[] args)
   at GLib.Signal.ClosureInvokedCB(Object o, ClosureInvokedArgs args)
   at GLib.SignalClosure.MarshalCallback(IntPtr raw_closure, IntPtr return_val, UInt32 n_param_vals, IntPtr param_values, IntPtr invocation_hint, IntPtr marshal_data)

probably not related, but just in case: "ll /run/user/1000/doc/ | grep 95720e22" shows "drwx------ 2 dylan dylan ..."

note: It works just fine if I save it somewhere else like ~/Desktop/

[James Carroll (james-carroll)]

The `/run/` path isn't really meant to be shown to users. It appearing at all is a quirk of the design of the XDG portals being used in the Snap, and I'm imagining trying to use the portals on documents already in the portals is causing some circular logic that's causing this problem.

I'd expect that the "save" button works fine, it's exclusively "Save As" trying to create a new file over the old one, that already happens to be in the portals documents storage.

In 22.04, you'd be less likely to experience this, as the portals should identify files in $HOME and /mnt or /media as being inside the scope of the sandbox anyway, and so shouldn't treat the path specially.

And apparently in v1.18 of the portals, this is fixed entirely; the portals will automatically convert the `/run` path back into the real path automatically. Unfortunately for Ubuntu this means using 23.10 or newer.

It might be possible for Pinta to workaround this (can we force "Save As" to default to $HOME?), but in theory it's already fixed now at least if you're on a newer base distribution.

[Cameron White (cameronwhite91)]

Testing this out, it looks like Pinta gets a null Gio.File from the file chooser dialog which leads to the crash, so the file chooser portal isn't behaving as expected. While we could add some more error handling, I think in order to actually save successfully you'd just have to navigate to the real path (e.g. `~/Pictures` instead of the `/run/user/...` path

I think the cause of this is that Pinta remembers the last folder used with the file dialog and navigates to that folder when you next open a file dialog. This causes it to navigate to the /run path which seems to cause problems for the file chooser portal

[James Carroll (james-carroll)]

Hi Cameron, I'm just wondering if you'd happened to have tested with portals 1.18/Ubuntu 23.10 to confirm if the problem still exists there? (I would myself, but I mostly work with Linux in virtual machines and 23.10 seems to just crash everytime I try it on HyperV).

In theory, https://github.com/flatpak/xdg-desktop-portal/pull/1007/files should have fixed this for us.

Of course the problem is that the Flatpak/Snap will run on distributions that don't have this fix, and I'd rather not recommend people use PPA's to backport the functionality (nor could I even find one).

But if it does work, and presuming we could probe the version in use to see if it has this fix, I'd propose:

The Open File interface likely doesn't need touching, but defaulting to $HOME (or $SNAP_REAL_HOME for snap at least) might be a decent idea anyway, but isn't relevant for us here.

The Save File interface is a lot more problematic, but assuming we can identify the portals in use, either:
1) force the folder to open at $HOME, since the main point of using "Save As" is to create a new copy elsewhere, this isn't too unreasonable an assumption to make (and certainly better than `/run`)
2) Do nothing if the portals are new enough to to avoid the problem, in theory feeding the `/run` path back into FileChooser should actually work fine without changes.

[Dylan Gundlach (kb-zealot)]

I did indeed install it with snap btw

[Cameron White (cameronwhite91)]

I just tested with 23.10 and it seems to be fixed. With earlier versions (22.10 was a VM I had lying around, but likely 22.04 as you mentioned) this also doesn't happen for files under $HOME so I could only reproduce the crash with using another location like /tmp

If there is a reliable way to figure out that we're running in a sandboxed environment with the old portals version, then I think just defaulting "Save As" to ~/Pictures or whatever is an acceptable workaround