libreoffice help doesn't open in firefox (404 error on file:///tmp/lu417531j7po.tmp/NewHelp0.html)

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1951210

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

Issue also occurs in 21.10 release, using Lubuntu.

Installed the Firefox snap package, while leaving the Lubuntu 21.10-provided Firefox .deb package installed.

Launched LibreOffice Writer to see what the Help function did.

*It launched a Thunderbird compose window.*

Firefox snap package was then removed. The Thunderbird installation is the snap package.

Fresh install of Lubuntu jammy on
- hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)

Post install and using the fresh lubuntu system, opening LibreOffice - HELP - Libreoffice.Help

gets `firefox` opened &

FILE NOT FOUND - file://tmp/lu23267w8nw8.tmp/NewHelp1.htmp

I booted a *jammy live* system on another box & tried to re-create this issue and on one box I did not replicate it (but it's likely I booted a 20.04.4 ISO as I had that thumb-drive in my hand at the same time; d780), but a boot on d755-5 where I was careful to ensure wallpaper was correct & *jammy* thumb-drive was used DID replicate the issue in *live*.

Alas I've not been very thorough in recording which LibreOffice app I've opened in prior comments (it's usually one or two randomly I open), but I booted an QA-test install done earlier today on

- dell [optiplex] 780 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

NOTE: Install was an "install using existing partition" type; ie. no format of partition; so additional packages installed (manually installed) get re-installed etc, and user configs or anything that existed in $HOME isn't touched. This install was a 21.04 system prior to it's EOL where it became a jammy install (I forget what it was pre-21.04, but parts of my $HOME will be many cycles ago).

Either way - LibreOffice apps (math & draw I think I used) and LibreOffice - HELP - LibreOffice.Help did NOT show on error on either tried app; unlike the FRESH INSTALL

This issue still exists. The cause of the problem is that libreoffice generates a temporary HTML page somewhere under the system-wide /tmp, which contains a bit of javascript that redirects to file:///usr/share/libreoffice/help/index.html. But the firefox snap, being strictly confined, cannot see files under /tmp.

And apparently the reason for this convoluted solution is that xdg-open doesn't support URL parameters with file:// URLs (https://github.com/LibreOffice/core/blob/8cdfd9edce38447a3ab7660a0d534982bd9e69b1/sfx2/source/appl/sfxhelp.cxx#L942).

I just verified that indeed xdg-open (in fact gio that is invoked by xdg-open) is tripped by URLs with parameters.

This would require patching impl_showOfflineHelp() to write the temporary file to some place strictly confined snaps such as firefox can see, e.g. XDG_DOWNLOAD_DIR. Not exactly a clean solution, but better than failing to display the help altogether.

@osomon So putting the temporary file in XDG_DOWNLOAD_DIR works, but is not enough yet, since the firefox snap can't even read the real target. See "xdg-open /usr/share/libreoffice/help/index.html"

A patched version of libreoffice can be found at https://launchpad.net/~libreoffice/+archive/ubuntu/libreoffice-prereleases/+packages?field.series_filter=jammy

Right, snaps aren't allowed read-access to the host's filesystem in general but for a few exceptions. One of them is /usr/share/doc, so I'm wondering whether we could have libreoffice install its HTML documentation there (e.g. /usr/share/doc/libreoffice/help/), and symlink /usr/share/libreoffice/help to it.

This would require patching getHelpRootURL().

Installing those files to /usr/share/doc would oppose the Debian policy 12.3 - https://www.debian.org/doc/debian-policy/ch-docs.html#additional-documentation

Adding symlinks in /usr/share/doc/libreoffice/* back to /usr/share/libreoffice/* would be allowed.

Right, specifically this:

    « Packages must not require the existence of any files in /usr/share/doc/ in order to function. Any files that are used or read by programs but are also useful as stand alone documentation should be installed elsewhere, such as under /usr/share/package/, and then included via symbolic links in /usr/share/doc/package. »

I guess that leaves us with proposing an update to the snapd system-packages-doc interface, to allow read access to the host's /usr/share/libreoffice/help.

Submitted https://github.com/snapcore/snapd/pull/11588 to update the system-packages-doc interface.

This bug was fixed in the package libreoffice - 1:7.3.2-0ubuntu1

---------------
libreoffice (1:7.3.2-0ubuntu1) jammy; urgency=medium

  * New upstream release
  * Use XDG_DOWNLOAD_DIR as location for temporary file for offline help
    (LP: #1951210)

 -- Rico Tzschichholz <email address hidden> Mon, 04 Apr 2022 12:28:12 +0200

 A quick test using package

guiverc@d960-ubu2:/de2900$ apt-cache policy libreoffice
libreoffice:
  Installed: (none)
  Candidate: 1:7.3.2-0ubuntu1
  Version table:
     1:7.3.2-0ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages

and I'm getting a firefox tab opening with page being

---
File not found

Firefox can’t find the file at /usr/share/libreoffice/help/index.html?Target=swriter/.uno:HelpIndex&Language=en-US&System=UNIX&Version=7.3.

    Check the file name for capitalization or other typing errors.
    Check to see if the file was moved, renamed or deleted.
---

this is an installed system (rebooted this morning), I'll wait and re-test when we have a daily ISO available with this package to confirm if it occurs there, or with a fresh install.

the 'new' error message has been reported on https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1967971

no new ISO exists currently, but it occurs on a lubuntu 'live' daily with packages upgraded prior to test.

This still requires a snapd 2.55.3 release. See https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1951210/comments/14

This is still occurring on Lubuntu jammy 2020-04-13
(daily live; starting libreoffice & seeking help)

snapd package is according to `apt-cache policy snapd`

Installed: 2.55.3+22.04

Chris, yes, the snapd update isn't in Jammy currently. The correct command to check what version of snapd you are running is

snap info snapd

I think you'll need to restart once snapd is updated to get the fix.

It's correct for this bug to be Fix Released because there is nothing left to do on the LibreOffice side. The snapd update should be released soon (I don't have an exact schedule for it.)

Here is the output when I press F1 in LO 7.3.2.2, Ubuntu 22.04, ...

<!DOCTYPE HTML><html lang="en-US"><head><meta charset="UTF-8"><noscript><meta http-equiv="refresh" content="0; url='file:///usr/share/libreoffice/help/en-GB/noscript.html'"></noscript><meta http-equiv="refresh" content="1; url='file:///usr/share/libreoffice/help/index.html?Target=swriter/SW_HID_EDIT_WIN&Language=en-GB&System=UNIX&Version=7.3'"><script type="text/javascript"> window.location.href = "file:///usr/share/libreoffice/help/index.html?Target=swriter/SW_HID_EDIT_WIN&Language=en-GB&System=UNIX&Version=7.3";</script><title>Help Page Redirection</title></head><body></body></html>

Definitely a bug.

Also occurs in Lubuntu 22.04.

This appears to have regressed. I'm suspecting the changes in https://github.com/snapcore/snapd/commit/5abb3aab6b74db5a9e9920c537d673806603349a.

The bug is still consistently present in LO 7.3.4.2. Even when using a browser like FF or Chromium to open /usr/share/libreoffice/help/index.html results in the "File not found" error.

Copying the index.html file to ~/Downloads fixes the error (but produces a blank page in both browsers).

Om my Kubuntu 22.04.1 LTS PC the access rights of the folder /usr/share/libreoffice/help and index.html file are:
-rwxr-xr-x (755), owner = group = root

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

impish is EOL so removed.

If I load libreoffice on my primary kinetic box; and seek help, it switches to firefox (snap) but on firefox I get only

---
File not found

Firefox can’t find the file at /usr/share/libreoffice/help/index.html?Target=swriter/.uno:HelpIndex&Language=en-US&System=UNIX&Version=7.4.

    Check the file name for capitalization or other typing errors.
    Check to see if the file was moved, renamed or deleted.
---

snapd:
  Installed: 2.57.1+22.10

This issue also occurs with GIMP and Firefox. When trying to access the GIMP help folder with Firefox, it reports "File not found".

Steps to reproduce:

Firefox 104.0.1 snap in Kubuntu attempts to access the Gimp application help file "index.html" which is located in folder "/usr/share/gimp/2.0/help/en/" using command URL "file:///usr/share/gimp/2.0/help/en/index.html".

Actual results:

Firefox is unable to access that folder and reports the following:

File not found

Firefox can’t find the file at /usr/share/gimp/2.0/help/en/index.html.

Check the file name for capitalization or other typing errors.
Check to see if the file was moved, renamed or deleted.

Expected results:

Firefox should be able to access the folder and files at that location since they are accessible using the same user id with a bash command line command:

cat /usr/share/gimp/2.0/help/en/index.html

I'm afraid that Olivier is right. In the commit he linked to, the two lines

 apparmor.GenWritableProfile(emit, "/usr/share/libreoffice/help", 3)
 apparmor.GenWritableProfile(emit, "/usr/share/xubuntu-docs", 3)

were replaced with a single

 apparmor.GenWritableProfile(emit, "/usr/share/", 3)

I need to investigate this, but my first guess is that this has the effect of making firefox and chrome see a different /usr/share/ tree than the one from the host. I'll be investigating this.

Attaching the logs when running chromium. The /usr/share/libreoffice is missing from chromium's mount namespace, and the logs show that an error occurred when creating it:

======
change.go:446: DEBUG: remove "/tmp/.snap/usr/share" (error: <nil>)
change.go:320: DEBUG: mount name:"/var/lib/snapd/hostfs/usr/share/gtk-doc" dir:"/usr/share/gtk-doc" type:"none" opts:MS_BIND|MS_RDONLY unparsed:"" (error: <nil>)
update.go:85: cannot change mount namespace according to change mount (/var/lib/snapd/hostfs/usr/share/libreoffice/help /usr/share/libreoffice/help none bind,ro 0 0): cannot create directory "/usr/share/libreoffice/help": permission denied
======

and indeed there's an AppArmor failure about it:

audit[38124]: AVC apparmor="DENIED" operation="mkdir" profile="snap-update-ns.chromium" name="/usr/share/libreoffice/help/" pid=38124 comm="5" requested_mask="c" denied_mask="c" fsuid=0 ouid=0

It's possible (but I still have to study the code better) that the last parameter of apparmor.GenWritableProfile() needs to be a "2" instead of a "3". But I still have to understand why our integration tests didn't catch this failure, since they are actually verifying that the libreoffice dir is readable.

Proposed fix: https://github.com/snapcore/snapd/pull/12127

this error still occurs in Lubuntu kinetic (daily) using

snapd:
  Installed: 2.57.1+22.10.1

daily 20220915

(though it's working on my primary box running kinetic using the same procedures... my primary box though is heavily modified/bloated)

Hi Chris, that's expected, because the fix has only been committed to the repo, it's not in any release yet.

If you feel adventurous, you could use snapd from the edge channel ("snap refresh --channel=latest/edge snapd"), but it's not something I recommend to keep active, so if you feel like trying the latest version to verify whether the issue is really fixed you are very welcome to do so, but after doing that I'd recommend you to return to the stable version (same command as above, just with "latest/stable" as the channel) and live with this bug until the next major release.

Hello,

Same issue still occurs in french Ubuntu 22.04 installed.
Hit F1 open firefox with:
--------------------
Fichier introuvable

Firefox ne peut trouver le fichier à l’adresse /usr/share/libreoffice/help/index.html?Target=swriter/SW_HID_EDIT_WIN&Language=fr&System=UNIX&Version=7.3.

    - Vérifiez la syntaxe du nom de fichier (dont le respect des minuscules/majuscules) ;
    - Vérifiez si le fichier n’a pas été déplacé, renommé ou supprimé.
--------------------

snapd
 version: 2.57.1
 revision: 16778

Tried with latest/edge
 version: 2.57.3+git399.g7b37d59
 revision: 17220

But the error still occurs.

Same issue with Gimp with the url:
/usr/share/gimp/2.0/help/fr/index.html

Maybe occurs with other applications which use /usr/share/ for the help?

Same issue on Xubuntu 22.04.1 French, the 'file not found' URL is:

file:///usr/share/libreoffice/help/index.html?Target=scalc/.uno%3AHelpIndex&Language=fr&System=UNIX&Version=7.3