Jabref 'snap' package doesn't work on Ubuntu 20.04/18.04 -- can't link with LibreOffice

I have some issues with the installation of the 5.1.60000 ‘snap’ version of JabRef, as installed in Ubuntu 20.04 using ‘sudo snap install jabref’. Hopefully reporting here is the right thing. I think that @koppor is the maintainer of the package, so hopefully he’ll see this message.

The issue that I have is that after installing Jabref, I can’t link to LibreOffice to insert citations. If I straightaway click the leftmost ‘autodetection’ button in the LibreOffice ‘tool’, then I get an error dialog which contains the following text:

java.lang.IllegalStateException: Not on FX application thread; currentThread = pool-3-thread-1
at org.jabref.merged.module@5.1.60000/com.sun.javafx.tk.Toolkit.checkFxUserThread(Unknown Source)
at org.jabref.merged.module@5.1.60000/com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(Unknown Source)
at org.jabref.merged.module@5.1.60000/javafx.stage.Stage.(Unknown Source)
at org.jabref.merged.module@5.1.60000/javafx.stage.Stage.(Unknown Source)
at org.jabref.merged.module@5.1.60000/javafx.scene.control.HeavyweightDialog$1.(Unknown Source)
at org.jabref.merged.module@5.1.60000/javafx.scene.control.HeavyweightDialog.(Unknown Source)
at org.jabref.merged.module@5.1.60000/javafx.scene.control.Dialog.(Unknown Source)
at org.jabref.merged.module@5.1.60000/javafx.scene.control.Alert.(Unknown Source)
at org.jabref.merged.module@5.1.60000/javafx.scene.control.Alert.(Unknown Source)
at org.jabref@5.1.60000/org.jabref.gui.FXDialog.(Unknown Source)
at org.jabref@5.1.60000/org.jabref.gui.FXDialog.(Unknown Source)
at org.jabref@5.1.60000/org.jabref.gui.JabRefDialogService.createDialog(Unknown Source)
at org.jabref@5.1.60000/org.jabref.gui.JabRefDialogService.showInformationDialogAndWait(Unknown Source)
at org.jabref@5.1.60000/org.jabref.gui.openoffice.DetectOpenOfficeInstallation.selectInstallationPath(Unknown Source)
at org.jabref@5.1.60000/org.jabref.gui.openoffice.DetectOpenOfficeInstallation.autoDetectPaths(Unknown Source)
at org.jabref@5.1.60000/org.jabref.gui.openoffice.DetectOpenOfficeInstallation.isInstalled(Unknown Source)
at org.jabref@5.1.60000/org.jabref.gui.openoffice.OpenOfficePanel$1.call(Unknown Source)
at org.jabref@5.1.60000/org.jabref.gui.openoffice.OpenOfficePanel$1.call(Unknown Source)
at org.jabref.merged.module@5.1.60000/javafx.concurrent.Task$TaskCallable.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)

I discovered that the LibreOffice integration depends on the presence of the deb package ‘libreoffice-java-common’, so next I installed that. I still got the same error (as far as I can tell).

Then I tried using the second ‘detect’ button. It asks for a path to the OpenOffice/LibreOffice library. However, some freaky stuff to do with folder permissions appears to be happening – if I type in the correct folder, /usr/lib/libreoffice/program/classes, I get “no such file or directory”. If I attempt to navigate to that folder, I can’t see it at all. If I type “ls /usr/lib/libreoffice/program/classes” in a terminal as regular user, it clearly is there. I’m not sure if there is a solution possible here or not… perhaps this is a fundamental limitation of the ‘snap’ approach to doing things? (Down with 180 MB snap packages! Long live proper 8 MB deb and rpm packages!)

PS when I installed the jabref.org .deb version (JabRef download latest version), it worked immediately, without problems.

Please have a look at: https://docs.jabref.org/installation#troubleshooting

Hi there

Given that Ubuntu recommends users to install the snap package without any caveats, may I suggest that it would be a big help for the ‘Autodetect’ feature within Jabref itself to provide a clear user warning that the feature is unavailable in this snap-package version?

Cheers
JP

2 Likes

Indeed, I think this could be useful.
@LyzardKing is there way to detect if an app is installed as snap under linux? Or maybe some folder?

The snap and flatpak install methods do not integrate properly with libreoffice/third party apps.
I’m working on trying to fix this issue, but it’s not easy since the packages are sandboxed.
If we want to remove the functions or add a notice the easiest way to detect if it’s running in a snap is to check if the SNAP env variable exists.
In the flatpak the env variable is FLATPAK_SANDBOX_DIR

@Siedlerchr
Is it possible to split the commandPath (.split(" ")) in
return new String[] {commandPath, "--insert-cite", String.format("%s{%s}", getCiteCommand(), keyString)};
It’s in https://github.com/JabRef/jabref/blob/fa0106dcf28c3e754e5a770deeb5cc4c48cb0b38/src/main/java/org/jabref/gui/push/PushToTeXstudio.java#L28
The line in question would render possible the integration of third-party apps (escaping the sandbox) in the flatpak.
It would need to be changed also in the other editor functions…
But it shouldn’t be an issue if it’s not run in a flatpak…
A user would then change the path to flatpak-spawn --host <editor path>

Thanks, for the info will look into it the next days.
I will see if I can add at least show a notice. There’s also some threading error that needs to be fixed.

Other question, can snap A communicate/interact with snap B? If both are snaps?

Unfortunately not.
The flatpak can escape the confinement using the flatpak-spawn command I described earlier
a snap cannot escape the confinement if not using complicated permissions (like the ones we use for the extension)
The snap could be built to be a “classic” unconfined snap, so it has full access to the system.
When I built the snap in the first place there was a discussion on this, but it was decided to go with the confinement active.

1 Like