Fork off webbrowser call in case it fails to return

[ChrisJefferson]

Pull Request Checklist

• [x ] I’ve read the guidelines for contributing.
• [ x] I updated AUTHORS.txt and CHANGES.txt (if the change is non-trivial) and documentation (if applicable).
• [ x] I tested my changes.

Description

calls to webbrowser.open do not return for command-line browser, so run it in a fork

[ChrisJefferson]

This fixes the issue discussed in #3536 (command line browsers hang). As discussed there, there are better things to do than this (open a GUI browser, set the BROWSER variable), but this at least means nikola does not appear to hang.

[Kwpolska]

1. This doesn’t work on (non-WSL) Windows, it doesn’t have os.fork.
2. The affected browsers will be unusable due to logs being written.

Here’s a better idea of a fix:

browser = webbrowser.get()
if browser.background or user_on_windows:
    browser.open(url)
else:
    # Tell user that their browser is mediocre and offer 3 options:
    # Standard open (with logs)
    # Open without logs (requires forking)
    # Don't open, just serve

[ChrisJefferson]

I did forget os.fork() wasn't on normal windows.

Thanks, I'm going to go and think about this, annoyingly one needs to pick a bit through the hierarchy (I seem to actually have a GenericBrowser, which doesn't have browser.background) -- I'm not sure if GenericBrowser will, in some cases, return promptly, in which case this might be a lost cause (without an upstream fix of some kind).

[Kwpolska]

You could do this:

In [4]: getattr(webbrowser.get(), 'background', False)
Out[4]: False

[ChrisJefferson]

Hi,

Unfortunately, it looks like command line browsers, and browsers defined with the BROWSER variable, are both handled as GenericBrowser objects, so I can't tell if they are going to return quickly or not. Further, WindowsDefault doesn't have background either.

The best option I can think of is to specifically check getattr(webbrowser.get(), name, "") == "www-browser", which (seems to) catch the default configuration of Linux with only a terminal browser installed (checked on a couple of machines I can SSH into), and www-browser is only ever supposed to be a command-line terminal.

[Kwpolska]

www-browser isn’t even present on my Fedora server, and the browser detected is links.

[ChrisJefferson]

Argh! :) I hoped all linux distros would install that, maybe it's a debian thing?

i could just hardwire ["www-browser", "links", "elinks", "lynx", "w3m"], based on https://github.com/python/cpython/blob/3.9/Lib/webbrowser.py ? Sorry, this is clearly taking longer than it's probably worth, but I feel invested now.

[Kwpolska]

Hardcoding those browsers sounds like a good idea to me. (And feeling invested in a PR, big or small, is certainly great for the project!)

[Kwpolska]

www-browser is a weird thing. My Kubuntu 20.04 machine doesn’t have it. My WSL2 system does:

[kwpolska@Kw-Farore ~win]% www-browser -h
www-browser - Part of wslu, a collection of utilities for Windows 10 Windows Subsystem for Linux
Usage: wslview (--register|--unregister|--help|--version) [LINK]

For more help for www-browser, visit the following site: https://github.com/wslutilities/wslu/wiki/www-browser

And then running www-browser http://example.com/ opens that page in Firefox on Windows. And so does nikola serve -b as it is right now.

WSL seems to ship with https://github.com/wslutilities/wslu by default, and it does the right thing, but installing eg. elinks will replace the tool with a Debian alternative that defaults to said elinks. This sounds like a bug that should be reported to Microsoft.

[ChrisJefferson]

OK, so if your www-browser is firefox, and mine is lynx, as you say this isn't fixable nicely by us. I also previous found a page that said www-browser should be command line, but in debian it can be provided by chromium and firefox, so that's off as well.

Hmm.. that brings us back to (I think) -- do the "open with fork", have the logs mixed in if someone has a terminal, and assume they'll realise that means they have to go and run the browser somewhere else if they don't want messages mixed in. While that's bad, it's an improvement on the current (in my opinion), where it seems to hang so it's not obvious what's to blame.

[Kwpolska]

I think we could include www-browser in the “terminal blacklist”, if we give users the option to pick the way in which the browser should run.

[aknrdureegaesr]

open ? (x-www-browser ?)

This is from a Debian point of view. My machine is running the current stable Debian version Bullseye.

I suggest calling open (which is a symbolic link to xdg-open) on some .html - file or some URI. That should be correctly configured to whatever browser the user wants. As an additional benefit, that returns quickly and does not wait for the application to terminate (at least in my experience).

open is also implemented on other systems. Iirc, Mac has it. Windows I havn't used for ages, but may have it, too.

If a browser is to be called directly - well, my machine does not have www-browser in its file system:

andreas@meise:~/comp/2023-10-09_static_site_generatoren
$ www-browser
bash: www-browser: command not found

What does exist in my system is

andreas@meise:~/comp/2023-10-09_static_site_generatoren
$ ls -l /usr/bin/x-www-browser
lrwxrwxrwx 1 root root 31 Mar 15  2020 /usr/bin/x-www-browser -> /etc/alternatives/x-www-browser

so you may consider adding that to a default list.

Unrelated, won't help us: www-browser does exist as a functionality marker in the Debian package system:

$ dpkg -s firefox-esr
Package: firefox-esr
Status: install ok installed
Priority: optional
Section: web
Installed-Size: 233122
Maintainer: Maintainers of Mozilla-related packages <[email protected]>
Architecture: amd64
Version: 115.3.1esr-1~deb11u1
Provides: gnome-www-browser, www-browser
...