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.

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

Issue opening file in Flatpak-based browser #23

Open
aryzing opened this issue Apr 9, 2023 · 2 comments
Open

Issue opening file in Flatpak-based browser #23

aryzing opened this issue Apr 9, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@aryzing
Copy link

aryzing commented Apr 9, 2023

Was redirected here from rust-lang/cargo#8428. Given cargo doc --open uses this tool internally, seems like taking a look at opener could help resolve that issue. I'm not familiar with how the two tools interact, although if it helps, when trying to open rust docs, the path that actually loads into the browser looks something like,

file:///run/user/1000/doc/486cb8d0/index.html

instead of the locally generated html file.

Using Ubuntu 22.10 with Brave browser flatpak.

@Seeker14491
Copy link
Owner

The opener crate delegates to xdg-open on Linux. Not sure what I can do here.

@Seeker14491 Seeker14491 changed the title Issues openeing files in default browser Issue opening file in Flatpak-based browser Apr 11, 2023
@Seeker14491 Seeker14491 added the bug Something isn't working label Apr 11, 2023
@matta
Copy link

matta commented Oct 5, 2023

I was running into this same issue.

On my system, xdg-open is configured to run the flatpak version of Firefox. I suspect that whatever logic is doing this is taking the one html file passed on the command line and sandboxing it into a temporary directory, then passing that to Firefox. I don't know if this is a bug or a WAI from the point of view of flatpak.

I also found https://wiki.debian.org/DefaultWebBrowser#Opening_the_default_browser_from_a_script. So, at least on Debian systems, it is most "sensible" to open a browser with sensible-browser instead of xdg-open. On my system, sensible-browser ends up running gnome-www-browser, which also works when run directly.

pprof, a program run by Google, does something completely different that has always worked for me (but hard codes a preference for Chrome...): https://github.com/google/pprof/blob/f7f687d19a9829062f02a2dd6e9a6fb527dbf143/internal/driver/commands.go#L354

So, my workaround is running commands like gnome-www-browser target/doc/whatever/index.html directory.

The current contens of the sensible-browser script, on a Debian 12 system, is this:

#!/bin/sh

# Prevent recursive loops, where these values are set to this script
p="$(command -v "$0")"
[ -n "$BROWSER" ] && [ "$(command -v "$BROWSER" || true)" = "$p" ] && BROWSER=

IsError()
{
	# Operating system command not found
	[ "$1" -ne 126 ] && [ $1 -ne 127 ]
}

Run()
{
	"$@"
	ret=$?
	IsError "$ret"
}

if test -n "$BROWSER"; then
    Run "${BROWSER}" "$@" && exit "$ret"
fi

if test -n "$DISPLAY"; then
    if test -n "$GNOME_DESKTOP_SESSION_ID"; then
        if test -x /usr/bin/gnome-www-browser; then
            exec /usr/bin/gnome-www-browser "$@"
        elif test -x /usr/bin/x-www-browser; then
            exec /usr/bin/x-www-browser "$@"
        elif test -x /usr/bin/gnome-terminal && test -x /usr/bin/www-browser; then
            exec /usr/bin/gnome-terminal -x /usr/bin/www-browser "$@"
        fi
    fi
    if test -x /usr/bin/x-www-browser; then
        exec /usr/bin/x-www-browser "$@"
    elif test -x /usr/bin/x-terminal-emulator && test -x /usr/bin/www-browser; then
        exec /usr/bin/x-terminal-emulator -x /usr/bin/www-browser "$@"
    fi
elif test -x /usr/bin/www-browser; then
    exec /usr/bin/www-browser "$@"
fi

echo "Couldn't find a suitable web browser!\n" >&2
echo "Set the BROWSER environment variable to your desired browser.\n" >&2
exit 1;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants