python / python/cpython

webbrowser.open with file: URLs may launch editor instead of browser

Ouverte
#128,540 8 commentaires 2 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

stdlib type-bug
Langage dominant
Python
Étoiles
77.2k
Forks
35.9k
Métriques de merge des PR
Métriques de PR en attente

Description

Bug report

Transferred to https://discuss.python.org/t/support-for-file-urls-in-webbrowser-open/81612 until consensus is reached.

Bug description:

In the code:

import webbrowser
from pathlib import Path

index_html = Path.cwd() / "index.html"
webbrowser.open(index_html.as_uri())

It is common for xdg-open (on linux) or open location (on mac) or os.startfile (on windows) to be selected as the default browser. This is great and simple for http[s] urls, but when these are passed file:// urls, all of the above select the default opener for HTML files, which may not be a browser at all (commonly a text editor for developer systems).

I don't know if there's a way to indicate that Browser entries can handle given URL schemes, but when selecting a browser from the try list, ideally these generic 'open' mechanisms should be skipped for file: URLs. Even better, use standard APIs to lookup the default browsers for http[s] and invoke that explicitly, rather than relying on an interpretation of "open URL" which is only valid for http URLs.

I believe URLForApplicationToOpenURL is the current macOS API to look up the application for http:, which could be used to launch explicitly with a browser. I guess xdg-settings get is already the equivalent for most linux situations and preferred if available, which is great. I'm not sure there's a more general way to discover what xdg-open will do with http://, but we have occasional reports where xdg-settings get default-web-browser doesn't work and xdg-open is invoked and doesn't launch a browser (or launches a different browser). I've no idea what the Windows call would be, but this looks like the same question.

This appears to have been opened long ago as #37540 and erroneously closed as an Apple bug (all platforms exhibit this behavior, and I think the bug is pretty clearly in webbrowser's assumption that "open file://path.html" means "open file://path.html with a web browser" which does not appear to be what any of the platforms mean by the chosen API).

CPython versions tested on:

3.9, 3.10, 3.11, 3.12

Operating systems tested on:

Linux, macOS, Windows

Linked PRs
  • gh-130031
  • gh-130535
  • gh-130538
  • gh-130541

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Piste de recherche

Lisez Lib/webbrowser.py au niveau des implémentations des emplacements Linux xdg-open, Windows os.startfile et macOS open liées dans le rapport. Consultez d’abord la discussion transférée et les PRs liées, car le consensus et le travail proposé se trouvent ailleurs. Le travail serait considéré comme terminé lorsqu’un comportement multiplateforme pour les URL file: et les tests correspondants aurait été convenu.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Évaluation

Stack technique
python
Domaine
desktop, operating-systems
Type d'issue
Bug
Difficulté
5/5
Temps estimé
Plus d'une semaine
Activité
À l'abandon
Clarté
À clarifier
Accessibilité débutants
15/100

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.