Proposal: Improving LibreOffice Plugin Installation under Linux

jbauss

Hey everyone,

I would like to propose a small but impactful change to the zotero-libreoffice-integration logic to solve persistent LibreOffice plugin installation issues under Linux.

The Problem

Nowadays, many users use the (unofficial) Zotero Flatpak. In my eyes, Flatpaks are arguably the best way to install GUI apps distro independent on Linux as the official way to install Tarballs is harder to understand for non-tech users than to click "install" in a graphical store.

However, the current plugin installation logic relies on scanning hardcoded paths (like /usr/lib/libreoffice or /opt) to find the unopkg binary.
Since Flatpaks are sandboxed, Zotero cannot see these system directories. This results in the installation failing silent or reporting "NotFoundError: Could not get children of file(/opt) because it does not exist" forcing users to use complex manual workarounds or mess with permission overrides.

This issue appears frequently in bug reports[1] [2] [3], showing that it is a common source of frustration.

The Solution

Instead of relying solely on detecting the unopkg binary path, Zotero should attempt a "Headless/GUI-based" installation as a fallback.

Platform-native file handling (nsIFile.launch()) effectively delegates the action to the Host OS (via xdg-open or Desktop Portals). If the user has LibreOffice installed (regardless of whether it is native Deb/RPM, Flatpak, or Snap), the OS will know how to handle the bundled .oxt file.

It is understandable that the Zotero team does not currently have the capacity to maintain an official Flatpak manifest. However, this fix would make the existing codebase "sandbox-aware" without requiring any Flatpak-specific maintenance from the core team.

Proposed Implementation

The logic would be added to resource/installer.mjs inside the Plugin.install method. If no installations are detected via path scanning, trigger the system handler. The code snippet is vibe-coded and therefore acts only as an example.

// Inside installer.mjs

var installations = await this.getInstallations();

// PROPOSED ADDITION:
// Fallback for Sandboxed environments (e.g. Flatpak) where detection fails
if (Object.keys(installations).length === 0 && Zotero.isLinux) {
    try {
        let oxt = this.getOxtPath();
        if (oxt.exists()) {
            Zotero.debug("LO-Integration: No unopkg found. Fallback to system handler for .oxt");
            
            // This triggers xdg-open/Portals, bypassing the Sandbox file system limits
            // The Host OS will open LibreOffice to install the extension.
            oxt.launch(); 
            
            // Optional: Alert the user that a manual confirmation in LO is required
            let ps = Components.classes["@mozilla.org/embedcomp/prompt-service;1"]
                     .getService(Components.interfaces.nsIPromptService);
            ps.alert(null, "LibreOffice Integration", 
                "Zotero launched the extension installer manually via your system.\n" +
                "Please confirm the installation in the LibreOffice window that just opened.");
                
            zpi.success(); // Treat as success so Zotero stops prompting
            return; 
        }
    } catch (e) {
        Zotero.logError("LO-Integration: Fallback failed: " + e);
    }
}

Benefits

• Zero Config for Users: Users on Silverblue, SteamOS, or standard distros using Flatpak no longer need to use workarounds to install the plugin. It "just works" (albeit with one extra confirmation click in LibreOffice).
  
• Zero Maintenance for Devs: Zotero no longer needs to track where different Linux distros hide their LibreOffice binaries.
  
• Security: This method respects the sandbox. There is no need to grant Zotero read/write permissions to system folders like /usr or /opt.
  

If you, the Zotero team, decide to maintain an official Flatpak in the future, this solution remains valid and robust because the sandboxing constraints will still apply.

Thanks for considering this.

Best regards,

Jan-Luca