On Wed, 26 Aug 2026 21:45:52 GMT, Phil Race <[email protected]> wrote:
>The browser can handle more schemes than http and https, eg file >So we have to give it its chance with whatever scheme. >So the current behaviour is more in line with the spec than the historic >behaviour. >The problem with this is that the browser has no way to report back that it >doesn't know what to do. >Which means that nothing gets to the fallback case For sure, the browser can handle more schemes than https and http, and that is how it was handled previously: applications, including browsers, were registered in the OS for each specific schema, and the OS dispatcher called the application based on the passed URL. Now it works differently(not better) and for example: "http123://example.com" was always rejected before, and now it is passed to the application registered as a browser as-is without any validation(which is by itself is a big concern). And that old behavior was clearly aligned with the specification. >The over-loading of the "browse" API to launch desktop applications is the >heart of the issue. >That might have been intentional but was it right ? I am not sure where this misleading information comes from. This is a java.awt.Desktop class, with a set of methods to run applications registered in the system for printing, editing, and opening URLs, with a spec that it can start the application. It is an analogue of gtk_show_uri_on_window/gnome_url_show etc on all platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32247#issuecomment-5432625866
