Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Can't use LibreOffice's Help, or HTML files with accompanying CSS files, in Flatpaked browsers #555

Open
wjt opened this issue Dec 18, 2020 · 2 comments
Open

Can't use LibreOffice's Help, or HTML files with accompanying CSS files, in Flatpaked browsers #555

wjt opened this issue Dec 18, 2020 · 2 comments

Comments

@wjt
Copy link
Contributor

wjt commented Dec 18, 2020

Flatpak:ed LibreOffice ships an offline version of its extensive documentation in a runtime, org.libreoffice.LibreOffice.Help. My default web browser is also a Flatpak application. (It doesn't particularly matter which one because all of Chromium, Firefox and Epiphany exhibit all the problems described here, with one exception that I will call out.)

When I hit F1 in LibreOffice, as best I can tell it writes a temporary file to some location or other, then invokes xdg-open or equivalent on it. I see the OpenFile method call (with just an FD), then the browser being activated on /run/user/1001/doc/dcca5ada/NewHelp1.html.

That file is as follows, though I have pretty-printed it for legibility:

<!DOCTYPE HTML>
<html lang="en-US">

<head>
    <meta charset="UTF-8">
    <meta http-equiv="refresh" content="1; url='file:///var/lib/flatpak/runtime/org.libreoffice.LibreOffice.Help/x86_64/stable/22757a622f8d4a5cb563e0249b84d2ef425c96d4b16e3dbdb692d199ea1e086c/files/index.html?Target=swriter/SW_HID_EDIT_WIN&Language=en-GB&System=UNIX&Version=7.0'">
    <script type="text/javascript">
        window.location.href = "file:///var/lib/flatpak/runtime/org.libreoffice.LibreOffice.Help/x86_64/stable/22757a622f8d4a5cb563e0249b84d2ef425c96d4b16e3dbdb692d199ea1e086c/files/index.html?Target=swriter/SW_HID_EDIT_WIN&Language=en-GB&System=UNIX&Version=7.0";
    </script>
    <title>Help Page Redirection</title>
</head>

<body></body>

</html>

So, the browser opens at that file, and follows the redirect to file:///var/lib/flatpak/runtime/org.libreoffice.LibreOffice.Help/x86_64/stable/22757a622f8d4a5cb563e0249b84d2ef425c96d4b16e3dbdb692d199ea1e086c/files/index.html?Target=swriter/SW_HID_EDIT_WIN&Language=en-GB&System=UNIX&Version=7.0, which of course it cannot access because that path on the host is not visible in the sandbox.

One part of the issue here is that LibreOffice has this indirection through a temporary file. Flatpak is able to arrange for that path to be accessible to the target application through the document portal, but has no idea that the target application will try to open a completely different path. I assume that it does this because it wants to pass query parameters through to the target application (which is not supported by OpenFile), and OpenURI explicitly does not support file:/// URIs.

But even without that indirection, there is still an issue. Suppose I have the following two files, index.html and index.css, somewhere in my home directory:

<!DOCTYPE HTML>
<html lang="en-US">
<head>
  <link rel="stylesheet" href="./index.css">
</head>
<body>
  <h1>Hello World</h1>
</body>
</html>
h1 {
  color: red;
}

When I use Nautilus to open index.html in Epiphany or Firefox, they are passed a document portal path. But only index.html is mapped, not its sibling file, so the text is black, not red. (Chromium currently has access to home for reasons, so this can't be reproduced there.)

Some possible approaches:

  • Sidestep this entirely by giving LibreOffice its own web view, which would be in the same sandbox and would be able to access the same help.
  • Make LibreOffice run a web server on localhost, and have it launch that URL in the default browser (which could also avoid the need for a temporary file)
  • Make it possible to open an HTML file and have the entire parent directory mapped through the document portal, not just the file itself

I'm not entirely sure what the conditions for the third approach would be – it's by design that opening a file does not share the entire directory tree in general, because then opening a file in ~ would give the app access to the whole home directory. So I guess it would need to be opt-in by the requesting application.
@wjt
Copy link
Contributor Author

wjt commented Dec 18, 2020

@ramcq You made a reference to a previous conversation about a --with-folder argument for xdg-open or perhaps flatpak run --file-forwarding that had been mooted. I can't remember where and/or with whom you had discussed that!

@wjt wjt changed the title Can't use LibreOffice's Help, or HTML files with accompanying CSS files, in sandboxed browsers Can't use LibreOffice's Help, or HTML files with accompanying CSS files, in Flatpak:ed browsers Jun 15, 2021
@wjt wjt changed the title Can't use LibreOffice's Help, or HTML files with accompanying CSS files, in Flatpak:ed browsers Can't use LibreOffice's Help, or HTML files with accompanying CSS files, in Flatpaked browsers Jun 15, 2021
@wjt wjt mentioned this issue Feb 23, 2022
Open
@Mikenux
Copy link

Mikenux commented Apr 14, 2023

I don't think this is a case for neighboring files which are about the host's files, not those of sandboxed applications or a runtime. It's more of a file-application association.

Also, asking a user if they are ok with opening index.html and others in a web browser to open help is definitely not good UX. It's something that should be asked like this: "LibreOffice wants to open help. Allow it with the following web browser? [list of installed web browsers] [+ checkbox to remember choice]". However, to use "help" as a word, we must know that it is indeed help...

An alternative can be flatpak having a dedicated "web engine" to display documents, or use that of a runtime if there is one (for example, that of the GNOME runtime). This should be intended for offline viewing (so no network access), so apps can use it as is without asking, all in a proper interface.

@GeorgesStavracas GeorgesStavracas moved this to Needs Triage in Triage Oct 2, 2023
@chrisawi chrisawi mentioned this issue Oct 12, 2024
Closed
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
No open projects
Triage
Status: Needs Triage
Milestone
No milestone
Development

No branches or pull requests
2 participants
@wjt @Mikenux