8354631: [macos] JFX - java.awt.desktop.OpenURIHandler is not receiving events

[pabulaner]

When trying to register an open URI handler when using JavaFX with a native menu, this task fails on Mac.
Either the native menu is not shown or the URIs are not received.

This pull request fixes this issue if AWT is registered after JavaFX, so that AWT runs embedded inside JavaFX.
It fixes this by introducing a native event to AWT, which can be used by JavaFX to forward events such as an openURL event.

The test for this pull request is non trivial, as the application needs to be installed on the Mac before it can be tested. Therefore the test is provided in a separate repository and it needs to be discussed if the test is necessary to have inside the JFX repo and if so, how it should be integrated.

JDK Pull Request: openjdk/jdk#24379
Co-Author: @FlorianKirmaier

Link to the test repo: https://github.com/pabulaner/openurifx

---

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-8354631: [macos] JFX - java.awt.desktop.OpenURIHandler is not receiving events (Bug - P4)

Contributors

• Florian Kirmaier <[email protected]>

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1755

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

Hi @pabulaner, welcome to this OpenJDK project and thanks for contributing!

We do not recognize you as Contributor and need to ensure you have signed the Oracle Contributor Agreement (OCA). If you have not signed the OCA, please follow the instructions. Please fill in your GitHub username in the "Username" field of the application. Once you have signed the OCA, please let us know by writing /signed in a comment in this pull request.

If you already are an OpenJDK Author, Committer or Reviewer, please click here to open a new issue so that we can record that fact. Please use "Add GitHub user pabulaner" as summary for the issue.

If you are contributing this work on behalf of your employer and your employer has signed the OCA, please let us know by writing /covered in a comment in this pull request.

[openjdk]

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

[kevinrushforth]

@pabulaner We'll take a look once your OCA is recorded.

/reviewers 2

[openjdk]

@kevinrushforth
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

[openjdk]

@pabulaner Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See OpenJDK Developers’ Guide for more information.

[kevinrushforth]

@pabulaner In order for your OCA status to be verified, you need to respond to the bot's instructions to confirm your OCA status by entering /covered, if you are covered by your employer's OCA, or /signed, if you signed the OCA yourself.

[pabulaner]

/signed

[bridgekeeper]

Thank you! Please allow for up to two weeks to process your OCA, although it is usually done within one to two business days. Also, please note that pull requests that are pending an OCA check will not usually be evaluated, so your patience is appreciated!

[pabulaner]

Are there any news on my OCA status?

[kevinrushforth]

Are there any news on my OCA status?

@robilad Can you provide a status update?

[mlbridge]

Webrevs

• 00: Full (e999e891)

[robilad]

OCA processed and account now marked as verified in Skara

[kevinrushforth]

We'll need some sort of standalone test, even if it can't be automated, that we can use to test the fix. Something that isn't a full-blown app. The test program should be able to reproduce the problem without the fix and can then be used to verify the fix.

When testing, we will want to consider the following scenarios:

1. Pure JavaFX app (even though there isn't a java.awt.desktop.OpenURIHandler in this case, we need to make sure that it doesn't misbehave)
2. JavaFX + Swing app -- JavaFX Toolkit initialized first (I think this is the main case you want to handle)
3. JavaFX + Swing app -- AWT Toolkit initialized first (I presume this case already works, so the main thing is to ensure no regressions)

[kevinrushforth]

Also, since the proposed fix is in JavaFX, the JBS bug needs to be updated to the correct component/subcomponent/version. I can do that and also assign the bug to @FlorianKirmaier since you list him as a co-author of this fix. If you wish to have Skara record Florian as a co-author, you can use Skara's /contributor add command.

[kevinrushforth]

Also, since the proposed fix is in JavaFX, the JBS bug needs to be updated to the correct component/subcomponent/version.

I see that it's not quite that simple, since there is a corresponding AWT fix.

You cannot use the same bug ID for both a JDK fix and a JavaFX fix. File a separate bug for the JavaFX half of the fix, and use that new bug for this JavaFX PR. Perhaps @FlorianKirmaier can do this?

The two fixes will need to be done and tested both independently and together. It is OK if the bug isn't fully fixed without both halves of the fix. However, it is not OK for it to misbehave in some other way (exception, crash, etc) if you run a JavaFX without the fix with an JDK with the fix or vice versa.

So there now needs to be a matrix of testing that includes:

(JDK without/with fix) X (JavaFX without/with fix)

For each of those 4 cases you will need to test:

• JavaFX + Swing app -- JavaFX Toolkit initialized first
• JavaFX + Swing app -- AWT Toolkit initialized first

[pabulaner]

/contributor add @FlorianKirmaier

[pabulaner]

And thank You for the quick reply, I will look into it and ask @FlorianKirmaier for his support.

[openjdk]

@pabulaner
Contributor Florian Kirmaier <[email protected]> successfully added.

[FlorianKirmaier]

I've created a new ticket for the JFX Part of the fix:
https://bugs.openjdk.org/browse/JDK-8354631
@pabulaner Can you change the title and ticket number in the PR, so it matches with the new ticket?

Let me know, if i should change anything, in the ticket.

[pabulaner]

So I adapted the test to the new requirements.
The test can be found here:

https://github.com/pabulaner/openurifx

Currently I just put the JDK and JFX builds right into the repo, but they can be self build and easily changed inside the test script.
Maybe You can give me feedback if that is the test You expected or if it was something else @kevinrushforth .

When I tested it, it didn't seem to give any errors and worked without problems.

[pabulaner]

I refactored the test repository to make more transparent which version is used and how it is build.

[pabulaner]

@kevinrushforth could You please take a look again now?