RFR: 8360120: Bundled macOS applications not receiving OpenURL events when launched as subprocess [v2]
Phil Race
prr at openjdk.org
Thu Jul 3 22:09:40 UTC 2025
On Wed, 25 Jun 2025 07:03:33 GMT, Dmitry Kulikov <duke at openjdk.org> wrote:
>> Added an on-demand installation of the native OpenURL event handler to the `Application.setOpenURIHandler()`.
>>
>> This does not break the specification for the affected API, since the requirement of the application being bundled and containing `CFBundleURLTypes` in the `Info.plist` is still valid: macOS will neither launch nor send OpenURL events to an application that does not declare such capabilities it the bundle.
>>
>> Running tests on macOS showed no regressions after this patch. Other platforms are not affected.
>
> Dmitry Kulikov has updated the pull request incrementally with one additional commit since the last revision:
>
> Update copyright years
Let me try to understand this.
[1] On startup, if it is a bundled application (per macOS rules) JDK will currently install a *native* handler,
even though [2] nothing in the Java code may actually be installed to handle it ?
ie the startup code, does it "just in case" ...
[3] And unless the native handler is installed, macOS will never ask the app to handle the URL.
Now the Java app doesn't actually care about no native handler ie [3] unless it calls setOpenURIHandler(), unless macOS has some built-in default that might be useful - but I doubt that.
Once the Java app does call setOpenURIHandler() it would clearly like to have its handler called - although according to what you say - macOS will still only do that if it is a bundled app.
At this point if no native handler is installed by [1], your change will install it, so from then on macOS will - for a bundled app - start sending it messages.
What I am getting out of this is that
(a) the installation of the native handler during startup is arguably pointless and we should always just install it when we know its needed - as in this change
(b) the checks that start up does are pointless
I'm guessing for "safety" you decided to leave those alone ?
But I'm not sure if these are really equivalent.
I don't know how [bundle _hasEAWTOverride:@"URLHandler"] is accounted for or whether it matters.
I am probably missing a key piece, but it seems to be an alternative way to get macOS to send messages,
but if that's the case, I don't know why it matters at all whether we check and whether Apple still support it.
Is there a possibility of a regression test here ? I'm guessing it would be might hardy but I've got to ask.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/25967#issuecomment-3033810216
More information about the client-libs-dev
mailing list