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

Bug #1951210 reported by Chris Guiver
106
This bug affects 19 people
Affects Status Importance Assigned to Milestone
libreoffice (Ubuntu)
Fix Released
Medium
Rico Tzschichholz
Jammy
Fix Released
Medium
Rico Tzschichholz
snapd (Ubuntu)
Fix Committed
Critical
Alberto Mardegan
Jammy
Confirmed
Critical
Unassigned

Bug Description

Ubuntu jammy live QA-test on
- dell [optiplex] 780 (c2q-q9400, 8gb, amd/ati cedar radeon hd 5000/6000/7350/8350)

Opened LibreOffice Writer as random apps in QA-test.
Hit F1 to call help, and all I get is an error

URL: file:///tmp/lu417531j7po.tmp/NewHelp0.html

---
File not found

Firefox can’t find the file at /tmp/lu417531j7po.tmp/NewHelp0.html.

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

Firefox opens as a snap; but it isn't accessing the data from LibreOffice.

Reported first at https://forum.snapcraft.io/t/firefox-snap-breaks-libreoffice-deb/27537

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: libreoffice-writer 1:7.2.2-0ubuntu0.21.10.1
ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14
Uname: Linux 5.13.0-19-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu73
Architecture: amd64
CasperMD5CheckResult: pass
CasperVersion: 1.465+canary3.3
CurrentDesktop: ubuntu:GNOME
Date: Wed Nov 17 04:46:33 2021
LiveMediaBuild: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20211116)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=C.UTF-8
 SHELL=/bin/bash
SourcePackage: libreoffice
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Chris Guiver (guiverc) wrote :
Chris Guiver (guiverc)
description: updated
Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

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

tags: added: iso-testing
Chris Guiver (guiverc)
summary: - libreoffice help doesn't open firefox (404 error on
+ libreoffice help doesn't open in firefox (404 error on
file:///tmp/lu417531j7po.tmp/NewHelp0.html)
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in libreoffice (Ubuntu):
status: New → Confirmed
Revision history for this message
Edward (epp1) wrote :

Issue also occurs in 21.10 release, using Lubuntu.

Chris Guiver (guiverc)
description: updated
Revision history for this message
Edward (epp1) wrote (last edit ):

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.

Revision history for this message
Chris Guiver (guiverc) wrote (last edit ):

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*.

tags: added: impish
Revision history for this message
Chris Guiver (guiverc) wrote :

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

Jeremy Bícha (jbicha)
tags: added: snap
Revision history for this message
Olivier Tilloy (osomon) wrote :

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).

Changed in libreoffice (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Olivier Tilloy (osomon) wrote :

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.

Revision history for this message
Rico Tzschichholz (ricotz) wrote :

@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

Revision history for this message
Olivier Tilloy (osomon) wrote :

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().

Revision history for this message
Rico Tzschichholz (ricotz) wrote :

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.

Revision history for this message
Olivier Tilloy (osomon) wrote :

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.

Revision history for this message
Olivier Tilloy (osomon) wrote :

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

Changed in libreoffice (Ubuntu):
status: Confirmed → Triaged
Changed in libreoffice (Ubuntu Jammy):
milestone: none → ubuntu-22.04
Changed in libreoffice (Ubuntu Jammy):
assignee: nobody → Rico Tzschichholz (ricotz)
Changed in libreoffice (Ubuntu Jammy):
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in libreoffice (Ubuntu Jammy):
status: Fix Committed → Fix Released
Revision history for this message
Chris Guiver (guiverc) wrote (last edit ):

 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.

Revision history for this message
Rico Tzschichholz (ricotz) wrote :
Revision history for this message
Chris Guiver (guiverc) wrote :

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

Revision history for this message
Jeremy Bícha (jbicha) wrote :

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.)

Revision history for this message
Rob Grune (rg-pigl) wrote :

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.

Revision history for this message
Edward (epp1) wrote :

Also occurs in Lubuntu 22.04.

Revision history for this message
Olivier Tilloy (osomon) wrote :

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

Revision history for this message
kubuntu4u2 (hjvdmolen) wrote :

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

Changed in snapd (Ubuntu Jammy):
importance: Undecided → Critical
Changed in snapd (Ubuntu):
importance: Undecided → Critical
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in snapd (Ubuntu Jammy):
status: New → Confirmed
Changed in snapd (Ubuntu):
status: New → Confirmed
Revision history for this message
Chris Guiver (guiverc) wrote :

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

tags: added: kinetic
removed: impish
Revision history for this message
Bill Weinel (bweinel) wrote :

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

Revision history for this message
Alberto Mardegan (mardy) wrote :

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.

Changed in snapd (Ubuntu):
assignee: nobody → Alberto Mardegan (mardy)
Revision history for this message
Alberto Mardegan (mardy) wrote (last edit ):

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.

Alberto Mardegan (mardy)
Changed in snapd (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
Alberto Mardegan (mardy) wrote :
Alberto Mardegan (mardy)
Changed in snapd (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Chris Guiver (guiverc) wrote (last edit ):

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)

Revision history for this message
Alberto Mardegan (mardy) wrote :

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.

Revision history for this message
nany (nany) wrote :

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?

Revision history for this message
Yosha872 (yosha) wrote :

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

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.