8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none

[crschnick]

A straightforward fix to just include MouseButton.NONE in the click counter map in cases weird mouse button events are sent. Alternatively, these events could also be ignored/dropped at some point

---

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-8375070: NPE in Scene.ClickGenerator::preProcess when mouse button is none (Bug - P4)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2034

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

Using diff file

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

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back crschnick! 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.

[mlbridge]

Webrevs

• 03: Full - Incremental (8735a4e9)
• 02: Full - Incremental (836b88eb)
• 01: Full - Incremental (f6f88a54)
• 00: Full (ea068f4c)

[andy-goryachev-oracle]

I'll try testing it, but it would be nice to learn more about the actual failure mode - which mouse model, which driver, etc.

[crschnick]

Yeah I would like to know as well, but that's the thing with user reports. Often they don't follow up, but an initial report is still better than nothing

[andy-goryachev-oracle]

The danger in such poorly understood cases is the risk of regression. This code was written in 2012 (or probably even earlier) and might have worked fine since then (or might not, it's hard to say).
In order to analyze the change, we do need a reproducible code example or instructions how to reproduce, per
https://bugreport.java.com/bugreport/

FAQ

guide to submitting a bug report

[andy-goryachev-oracle]

I've got the Logitech MX Anywhere 2S mouse with a bunch of extra buttons and no specially installed driver, and I cannot reproduce the exception with the latest master branch.

[crschnick]

Yes, I understand. The only reason I submitted this was because I have seen it multiple times now and the fix does not seem to have any adverse effects on other stuff.

It should be reproducible in headless mode when sending an event manually. I will try to create a reproducer for that.

[kevinrushforth]

/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).

[crschnick]

I added a test case to reproduce this issue.

I have two questions about the general workflow here:

1. If an issue is set to private, how does that happen / what does that mean? I was under the impression that all issues are public unless they are related to security or something. And the linked issue does not look like a security issue
2. How exactly is the requirement for a reproducer defined? Like if I observe that an issue is happening, but can't reproduce it manually, is a constructed test case good enough?

[kevinrushforth]

1. If an issue is set to private, how does that happen / what does that mean? I was under the impression that all issues are public unless they are related to security or something. And the linked issue does not look like a security issue

An issue can be set to Confidential for a few different reasons. In the case of the bug you asked about -- JDK-8110944 -- the component being fixed (glass) was not open source yet (note the resolution date: it was fixed in 2011). The bug didn't need to be Confidential, but no one noticed or asked about it until now.

2. How exactly is the requirement for a reproducer defined? Like if I observe that an issue is happening, but can't reproduce it manually, is a constructed test case good enough?

A constructed test case that fails before and passes after the fix is usually good enough as long as we understand why the failure is occurring and why the fix is the right one. So the questions being asked by @arapte are good questions to ask.

[crschnick]

So this is ready for review now with the test.

I have searched the various error logs that people sent me about unrelated issues, and found that this NPE occured for at least 5 people that reported other issues. All of those were on macOS 26, so something probably changed in the input handling there. Maybe it's a weird edge case or some accessibility thing, but it it definitely occurs somehow.

If someone with macos expertise wants to take a look at the root cause, then this can be fixed in a follow-up issue I guess. There is definitely something wrong in the input handling on macOS 26, I just can't pinpoint it yet