8388141: JavaFX.setOpenURIHandler() only receives event if application is already launched

[pabulaner]

Problem description

When You create a JavaFX native application with jpackage for macOS You will run into an issue when trying to handle URIs. When Your application isn’t running and You have it registered for handling certain types of URIs it won’t receive the first URI.

Here is a simple example:

If You have a JavaFX application that handles URIs for example of the form openurifx://your-content and You have it installed with jpackage for macOS and now You try to handle an URI by running the following command:

open openurifx://hello-world

The application will open, but it won’t receive the above URI. If You call the same command after the application is already running, everything will work fine and the application will receive the URI.

Problem cause

The cause of the problem is that when You build a JavaFX application and want to handle URIs You will have to combine JavaFX and AWT as AWT provides the URI handling capabilities. So the startup process is as follows:

1. JavaFX is initialized
2. JavaFX forwards the URI event to AWT
3. AWT is initialized
4. AWT is ready to handle URI events from JavaFX

The issue is that the URI event is delivered before AWT can handle it and therefore is simple dropped. That’s why later URIs will be received and are handled properly.

Fix

The fix is that JavaFX will wait until it receives a ready event from AWT so JavaFX knows that AWT is able to handle events now. After that it will forward all buffered URIs and therefore everything will be handled correctly. This means that the fix involves both the JFX and JDK repositories and needs to be integrated in both.

Note: In the case that a user has only a fix for the JFX part the URIs won’t be delivered at all, but there won’t be any error. This means that JavaFX applications won’t be able to handle any URIs so it might be an idea to add an environment variable to tell JavaFX to not wait for an AWT ready event. Then the first URI event would be lost, but at least all the following events would be handled properly.

Tests

To test the error and the fix You can clone this repository: https://github.com/pabulaner/openurifx and checkout the branch first-url. There You will find a README.md with further instructions.

PR inside the JDK: openjdk/jdk#31791

• I confirm that I make this contribution in accordance with the OpenJDK Interim AI Policy.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

• JDK-8388141: JavaFX.setOpenURIHandler() only receives event if application is already launched (Bug - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/2203/head:pull/2203
$ git checkout pull/2203

Update a local copy of the PR:
$ git checkout pull/2203
$ git pull https://git.openjdk.org/jfx.git pull/2203/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2203

View PR using the GUI difftool:
$ git pr show -t 2203

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/2203.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back pabulaner! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

The total number of required reviews for this PR has been set to 2 based on the presence of this label: rfr. This can be overridden with the /reviewers command.

[mlbridge]

Webrevs

• 00: Full (2de645c5)

[kevinrushforth]

@pabulaner You must not use the same JBS bug ID for a fix that spans JavaFX and JDK. You will need to file a new JBS issue for JavaFX and change the title of this jfx PR to use that new bug ID.

Also, this will need careful coordination and some discussion before it proceeds. I won't even have time to look at it before the jfx27 fork (and since JDK has already forked for JDK 28, this isn't a candidate for jfx27 anyway).

[kevinrushforth]

@pabulaner You must not use the same JBS bug ID for a fix that spans JavaFX and JDK. You will need to file a new JBS issue for JavaFX and change the title of this jfx PR to use that new bug ID.

I see that this is an old bug and was originally filed against the old javapackager (although is still relevant to running JavaFX with jpackage). I wonder if it would be better to use that original bug for the JavaFX half and file a new Bug or Enhancement request for AWT? Or maybe file a pair of new JBS issues -- one for JavaFX and one for AWT -- to better describe the problem.

Either way, you will need two bug ID: one for JavaFX and one for AWT.

[crschnick]

Whenever I used both AWT and JavaFX together, I force AWT to initialize before JavaFX as several other things can break as well when doing it the other way around. Is initializing JavaFX before AWT even officially supported?

[pabulaner]

I filed a new bug report with the help of @FlorianKirmaier and now the JDK and JFX PR have different JBS issues.
In this case the JFX issue just references the already present JDK issue as this seemed to be the most simple solution.

[prrace]

I don't see any harm in AWT sending such a message, although perhaps a CSR is needed.
The impact seems to be on the FX side, I don't know that I like that you essentially force the JDK-baseline for FX to be one that has this fix. Perhaps some other way to determine that AWT is loaded can be used. Or there should be a "cap" on how long it waits. I posted this comment in the JDK PR too.

[pabulaner]

I have thought about this issue too. Maybe it would be a solution to add an environment variable to toggle this behavior on and off on the JavaFX side. Something like "DISABLE_AWT_EMBEDDED_READY_EVENT".

Or maybe You have some idea on how to achieve the same effect with a different implementation.

[kevinrushforth]

I don't see any harm in AWT sending such a message, although perhaps a CSR is needed.

Quite possibly this would need a CSR depending on how it is done.

The impact seems to be on the FX side, I don't know that I like that you essentially force the JDK-baseline for FX to be one that has this fix.

Yeah, I don't like this aspect of the fix at all. As it stands, it will queue up these messages indefinitely if you run an FX that has this fix with JDK 27.

Perhaps some other way to determine that AWT is loaded can be used. Or there should be a "cap" on how long it waits.

Or both. However it is implemented, I think we need to do the following:

1. A timeout and/or a max queue length so that it doesn't queue up an effectively unlimited number of these messages
2. Either implement a detection mechanism that doesn't require an AWT event (not sure whether it is feasible), or add a version check to disable this feature if the JDK version is < 28. This would be in addition to a system property or env var to disable it.

Thinking out loud... another alternative would be for JavaFX to initialize AWT via a call to Toolkit.getToolkit() when we receive this event. That would mean the fix could be done entirely in JavaFX and you might not need to worry about queuing the messages, presuming the call could be done synchronously. This would need discussion and a CSR.