On Fri, 21 Aug 2026 11:51:56 GMT, Prasanta Sadhukhan <[email protected]> wrote:
>> `JDK has the following API : java.awt.Desktop.browse(URI) "Launches the >> default browser to display a URI." >> >> On Windows and macOS, the JDK used to call platform APIs to do this which >> would recognise some schemes as ones which would launch an associated >> application. For example on Windows "calculator:" is a scheme that windows >> may open the calculator, and on macOS "facetime:" may open the facetime >> application. >> >> Desktop.browse now always launches the browser directly, which is a problem >> for apps that took advantage of the previous behavior, since the browser >> itself may not re-direct to those applications. >> >> The current behaviour is intentional to provide a secure-by-default >> behaviour. >> >> The proposal here is to introduce an implementation system property ( >> **awt.desktop.browse_insecure**) which will allow apps to opt back into the >> old behaviour on Windows and macOS. >> >> The end-user, or the application, can set this property as a comma separated >> list of allowed schemes : >> >> -Dawt.desktop.browse_insecure=calculator,file >> >> where on Windows, the calculator and file scheme will be opened in open >> calc.exe and the File Explorer app respectively. >> >> or -Dawt.desktop.browse_insecure=* >> >> which allows all schemes. >> >> If -Dawt.desktop.browse_insecure is set or the scheme is in the allowed >> list, then JDK will open the URI using platform APIs which may open an >> associated app instead of the browser >> If -Dawt.desktop.browse_insecure is NOT set or scheme is NOT in the allowed >> list, the browser is explicitly launched and URI is handled by the browser - >> i.e. no change from current behaviour. >> >> >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Prasanta Sadhukhan has updated the pull request incrementally with three > additional commits since the last revision: > > - Use shared implementation > - Use shared implementation > - Use shared implementation Per the spec, the browse() API should first launch the desktop browser. Only if it cannot handle the URI should some other handler be invoked. 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 That's unfortunate, but we are unable to return to that historic behaviour by default of making the fall back the initial path. This PR provides a way for applications to opt-in to it, and since there's no spec change, it can be backported to provide some amount of relief. A future spec only update could do something about clarifying the behaviour, but I don't have suggested wording at this time. 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 ? Perhaps we can add a new open(URI) API which doesn't have to mention the browser at all. But it seems like it would just re-introduce similar problems so we'd have to think about it very carefully, and it would come with all sorts of dire warnings. It also could be considered a sort of duplicate of browse() which is another question mark. None of this is ideal for apps which have come to depend on this, but we are where we are. ------------- PR Comment: https://git.openjdk.org/jdk/pull/32247#issuecomment-5431492486
