You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
Bug report
Bug description:
In the code:
It is common for
xdg-open
(on linux) oropen location
(on mac) oros.startfile
(on windows) to be selected as the default browser. This is great and simple forhttp[s]
urls, but when these are passedfile://
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 forhttp[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 guessxdg-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 whatxdg-open
will do withhttp://
, but we have occasional reports wherexdg-settings get default-web-browser
doesn't work andxdg-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
The text was updated successfully, but these errors were encountered: