rustup doc has broken HTML pages on Fedora Silverblue

[joshua-stone]

Problem

Running rustup doc or rustup doc --book in Fedora Silverblue opens the web browser with temporary directories that in turn opens a broken HTML page. These pages are broken in the sense that CSS appears to missing, and clicking on a link will result in a File not found error:

file:///run/user/1000/doc/a80e7c5e/index.html

These directories only seem to contain index.html too:

$ find /run/user/1000/doc/a80e7c5e
/run/user/1000/doc/a80e7c5e
/run/user/1000/doc/a80e7c5e/index.html

This behavior persists regardless of whether it opens in the Firefox RPM or in the Firefox flatpak.

The pages themselves are actually intact, as they can be browsed from within rustup's install location:

file:///var/home/jstone/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html/book/index.html

Steps

1. Install Fedora Silverblue
2. Install rustup from the official instructions
3. Run rustup doc or rustup doc --book
4. Observe page URL in browser window

Possible Solution(s)

No response

Notes

$ distro 
Name: Fedora Linux 36.20220510.0 (Silverblue)
Version: 36
Codename: 
$ uname -a
Linux fedora 5.17.5-300.fc36.x86_64 #1 SMP PREEMPT Thu Apr 28 15:51:30 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Rustup version

rustup 1.24.3 (ce5817a94 2021-05-31)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.60.0 (7737e0b5c 2022-04-04)`

Installed toolchains

Default host: x86_64-unknown-linux-gnu
rustup home:  /var/home/jstone/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu (default)
nightly-x86_64-unknown-linux-gnu

installed targets for active toolchain
--------------------------------------

x86_64-unknown-linux-gnu
x86_64-unknown-linux-musl

active toolchain
----------------

stable-x86_64-unknown-linux-gnu (default)
rustc 1.60.0 (7737e0b5c 2022-04-04)

[kinnison]

This is fascinating because rustup doc literally just acquires the path to the HTML and invokes the browser. So unless Fedora Silverblue has done something odd to the environment etc. during the execution of rustup doc I'm not sure how this could happen.

Assuming you're able to compile code and it's just rustup doc that is being odd and not cargo doc --open then we can investigate it from our side. If OTOH other things are misbehaving then it sounds like Silverblue is doing something very odd which needs investigating from your side first.

If you run rustup show what does it say your rustup home is?

This behavior persists regardless of whether it opens in the Firefox RPM or in the Firefox flatpak.

Not reproducible in my test.
It seems to be a typical issue with Flatpak applications. Firefox Flatpak does not have permissions to access home directory.

The solution is to Install Flatseal and to grant firefox the filesystem permission to access ~/.rustup/toolchains using it.

[rbtcollins]

Makes sense, closing then.

[malachid]

#3422 says to use this ticket as a catchall.

For Ubuntu, the Firefox snap issue is captured here

My Chrome instance isn't a snap, so my workaround is to simply use a shell script to launch the same url in Chrome instead of Firefox; instead of using rustup doc. Not ideal, but a one line shell script to get around the incompatibility between the Firefox package and the rustup tool.

[malachid]

Updated method to still use Firefox:

• cargo install https -bin httplz
• make a shell script that calls httplz $HOME/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/share/doc/rust/html
• using script, load http://localhost:8000 in firefox