[snap] Cannot open attached file from e-mail

[Antoine Pitrou]

I installed the LibreOffice snap to get a newer version compared to the apt package. When I receive a LibreOffice document as attachment and try to open it from Thunderbird, I get the following error message:
"""
/tmp/mozilla-antoine0/mydoc.docx doesn't exist
"""

I don't understand the point of restricting filesystem access from a word processor.
At least this is a clear regression from the apt package.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[pwaring (launchpad-pwaring)]

In case anyone else hits this problem and is wondering about the root cause, it seems to be because snaps generally can't access data from other applications, so when Thunderbird drops a file into /tmp LibreOffice can't "see" it. This isn't unique to LibreOffice, it causes problems for other snaps as well (e.g. Chromium).

This doesn't happen with the non-snap version of LibreOffice distributed through the Ubuntu archive and available via `apt install`, so switching to that is a workaround, albeit at a lower version (6.4.2 instead of 7.0.2.2).

There are a few Ask Ubuntu posts with additional information and other workarounds:

https://askubuntu.com/questions/1123537/cant-open-file-attachment-with-libreoffice-snap

https://askubuntu.com/questions/1046890/libreoffice-cant-access-tmp-files-in-18-04

https://askubuntu.com/questions/1215305/how-can-i-grant-a-snap-application-access-to-tmp-via-command-line

[Sebastien Bacher (seb128)]

The issue is fixed now, the current snap revision uses the desktop portals which provides a picker on the real filesystem which allows to access any location the normal user can browser (the program still doesn't have access so it can't go read things it shouldn't, it requires user interaction to go pick from the selector)

[Sebastien Bacher (seb128)]

Sorry I mixed my tabs and though that was about thunderbird, libreoffice should probably start using portals as well to resolve the issue

[Sebastien Bacher (seb128)]

Or wait, you try to open the file from thunderbird in an email and it fails to open in libreoffice's snap (but works with the deb?)

[pwaring (launchpad-pwaring)]

The problem is if you have LibreOffice installed as a snap and try to open an attachment in Thunderbird, LibreOffice will generate an error message saying that it can open the file because it does not exist (in reality it does exist but LibreOffice can't read it, so the message is a bit misleading).

This is not a Thunderbird bug as the same thing happens if you try an open a file via Firefox (i.e. you click on a link to download a spreadsheet and select Open With: LibreOffice Calc).

If you have LibreOffice installed via apt then you can open files via Thunderbird and other applications, presumably because the .deb version is not confined in the same way as the snap.

[pwaring (launchpad-pwaring)]

Sorry, that should be: LibreOffice will generate an error message saying that it *can't* open the file

(Launchpad really needs a comment edit function!)

[Heather Ellsworth (hellsworth)]

In order to use portals, the Libreoffice upstream source needs to change their file dialogs to the newer gtk native APIs:

https://developer.gnome.org/gtk3/stable/gtk3-GtkFileChooserNative.html

So instead of using GtkFileChooserDialog, we should implement GtkFileChooserNative.

Since this is needed for the snap, we should submit a patch upstream refactoring their class to implement these changes. I think this would be very to good to have eventually but not a super high priority so marking this as a wishlist item.

[pwaring (launchpad-pwaring)]

I know this has been marked as 'wishlist', and perhaps it's not an issue for most people, but I've had to revert to using the .deb because this bug breaks my workflow every day (I receive and open lots of documents via email and through websites using Firefox).

[BjornW (bjornw)]

This bug is similar to the issue described in this older bug report https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1790608 I'm a bit disappointed that we've left a bug like this in a LTS release without a solution. It seems the snap approach is not yet on equal ux/ui footing with the previous approaches. Is there a way I can help with fixing this?