webbrowser does not handle opens under Windows WSL properly

[guidofioravantti]

BPO	45589
Nosy	@terryjreedy, @pfmoore, @tjguk, @zware, @zooba

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2021-10-23.17:33:22.416>
labels = ['type-feature', 'OS-windows', '3.11']
title = 'webbrowser does not handle opens under Windows WSL properly'
updated_at = <Date 2021-11-02.19:34:22.273>
user = 'https://bugs.python.org/guidofioravantti'

bugs.python.org fields:

activity = <Date 2021-11-02.19:34:22.273>
actor = 'guido.fioravantti'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Windows']
creation = <Date 2021-10-23.17:33:22.416>
creator = 'guido.fioravantti'
dependencies = []
files = []
hgrepos = []
issue_num = 45589
keywords = []
message_count = 6.0
messages = ['404896', '405482', '405534', '405535', '405537', '405539']
nosy_count = 6.0
nosy_names = ['terry.reedy', 'paul.moore', 'tim.golden', 'zach.ware', 'steve.dower', 'guido.fioravantti']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue45589'
versions = ['Python 3.11']

[guidofioravantti]

The 'webbrowser' module throws warnings and bad RC codes when running under Windows Subsystem for Linux (WSL).

This causes libraries that depend on the 'webbrowser' module to mistakenly assume there's been an error opening a URL. An example of this behaviour can be observed running jupyter-lab under WSL.

Steps to reproduce:

1. Run Ubuntu (for example) under Windows WSL.
2. python -m webbrowser https://www.python.org

Expected result:

The wesite opens.

Actual result:

The website opens but produces a No valid TTY message, which also yields a non-zero return code.

I have a patch for this bug that inspects the kernel version (platform.uname) and detects WSL. This is a similar solution that other projects have implemented to tackle this problem. For example, the fish shell project: https://github.com/fish-shell/fish-shell/blob/0e06a53dff5e198c4fcefb6419a53cf1267231a1/share/functions/help.fish#L83.

[terryjreedy]

Windows people, do we support running on WSL? Is there a buildbot running it?

[zooba]

We don't formally support it yet. We probably need somebody to develop expertise in the emulation layer so that they can work with the Linux distro experts to make sure their distros are doing things properly.

It has no relation at all to our Windows support (right now) - all versions of Python running in WSL 100% believe they are running on whichever Linux distro the user is running.

[guidofioravantti]

My code patch uses ‘wslview’, which is a binary that is injected into every
WSL distro and forwards file open commands to windows.

I detect WSL inspecting the kernel version, which includes WSL tagging.

On Tue, Nov 2, 2021 at 3:05 PM Steve Dower <[email protected]> wrote:

Steve Dower <[email protected]> added the comment:

We don't formally support it yet. We probably need somebody to develop
expertise in the emulation layer so that they can work with the Linux
distro experts to make sure their distros are doing things properly.

It has no relation at all to our Windows support (right now) - all
versions of Python running in WSL 100% believe they are running on
whichever Linux distro the user is running.

----------

---

Python tracker <[email protected]>
<https://bugs.python.org/issue45589\>

---

[zooba]

FWIW, I don't have wslview in the Debian distro I'm currently using. It
does have wslpath though.

Consistent detection and integration throughout CPython's standard
library (unless we believe we need special build options too) is
probably worth a python-dev discussion.

[guidofioravantti]

Understood, my mistake.

I wonder if explorer.exe or any other general purpose open command is
guaranteed to be available in all WSL distros. There’s also a consideration
to be made on WSL1 vs WSL2 (only v2 ships an actual Linux kernel).

For detection, there’re some other projects that have done this for some
time. Not sure they’re up to python-core standards, but I put an example
for the fish shell in my original description.

Might be worth looking into.

On Tue, Nov 2, 2021 at 3:28 PM Steve Dower <[email protected]> wrote:

Steve Dower <[email protected]> added the comment:

FWIW, I don't have wslview in the Debian distro I'm currently using. It
does have wslpath though.

Consistent detection and integration throughout CPython's standard
library (unless we believe we need special build options too) is
probably worth a python-dev discussion.

----------

---

Python tracker <[email protected]>
<https://bugs.python.org/issue45589\>

---

[mhils]

There's wslview, which seems to be installed by default in most WSL distros these days. The following works well:

webbrowser.get("wslview %s").open("https://example.com")

[davidhewitt]

It looks like a typical solution in the node ecosystem uses the open package to handle opening paths like this cross-platform. That uses the wsl.conf format to detect the correct configuration for launching, and uses the is-wsl package to handle the actual detection.

@zooba would a patch like that inside of webbrowser be appropriate? Or do you think the correct setup is to leave this to users to handle by configuring using tools like wslview?

Given that there's been no activity for a couple years on this issue, maybe system default wslview is working fine in most cases. I got here this morning due to an issue in logfire in combination with my local wslview binary being corrupt. (I think it's been grandfathered in from an old ubuntu version, I've upgraded my WSL2 in place several times over the years.)

[zooba]

I don't know the answer to that - WSL isn't actually Windows, so it's not really in my scope. It's the Linux build of Python that matters here.

[davidhewitt]

Ah, fair enough. Is there someone else we can ping to ask?

[mdboom]

This is only anecdotal from my own usage of WSL as my daily driver -- I have a new/default installation of Debian sid where

import webbrowser
webbrowser.open("https://google.com")

works through xdg-open which is configured (through no action on my part) to call wslopen.

Since xdg-open is the standardized way to open a webbrowser on Linux, IMHO it seems most appropriate for Python to continue to do that, and any bugs in that configuration would be the responsibility of any layers below it (the distro and/or its WSL-specific configuration).