lookup default browsers viaUrlAssociations\https\UserChoice if protocol is not http/https. ensureswebbrowser.open launches a web browser on Windows, even for URLs that are not http[s]. Only does the lookup for non-http URLs, limiting the impact of the change.

ensures browser is opened for e.g.file:// URLs, wherestartfile opens file by association. Launching custom protocols explicitly goes through the browser instead of throughstartfile. The end result isusually the same, after a prompt, unless the browser has explicit support/configuration for the protocol. Alternative: only lookup forfile:// instead ofnothttp[s]://.

Added extremely basic test exercise, the registry lookups are not actually covered, but I have tested them by hand. I'm not sure how to write good tests for the registry stuff.

Addressesgh-128540 on Windows only.

Open questions:

• custom URLs:os.startfile("ssh://some-host") might start putty or something, whereas this explicitly launches the browser (which would in turn typically prompt "launch external application PuTTy..?"). Behavior for custom URLs is previously undefined and inconsistent, but after this PR, it consistently launches a webbrowser if it can, but remainsundefined.
• are there more ways/times/versions for this to fail? It works in my tests, but I don't know all the different situations on Windows wrt versions, permissions, UWP, etc.
• Can theopen command-line lack%1 and still be valid (e.g. withappend)? I can't find a spec for this, so it would be good to know. I've gone with the most conservative, which is to assume it doesn't work if%1 is not present, falling back on previousos.startfile in that case.

Links:

• More discussion inhttps://discuss.python.org/t/support-for-file-urls-in-webbrowser-open/81612
• Backported implementation for testing inhttps://pypi.org/project/webbrowser-open/
• macOS counterpart:gh-128540: lookup default webbrowser on macOS #130535
• Linux counterpart:gh-128540: launch default browser more often on Linux #130541