-
Notifications
You must be signed in to change notification settings - Fork 505
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true #965
Conversation
👋 Welcome back karthikpandelu! A progress list of the required criteria for merging this PR into |
Webrevs
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Providing few quick comments about the test.
public static void main(String[] args) { | ||
initFX(); | ||
try { | ||
SliderTooltipNPETest test = new SliderTooltipNPETest(); | ||
test.testSliderTooltipNPE(); | ||
} catch (Throwable e) { | ||
e.printStackTrace(); | ||
} finally { | ||
exit(); | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
main()
method is not required, can be removed.
dragSliderAfterTooltipDisplayed(DRAG_DISTANCE, true); | ||
} | ||
|
||
private void dragSliderAfterTooltipDisplayed(int dragDistance, boolean xIncr) throws Throwable { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
boolean xIncr
is not required for the test. It can be removed along with it's use on line 101.
robot.mouseMove((int)(scene.getWindow().getX() + scene.getX() + SCENE_WIDTH/2), | ||
(int)(scene.getWindow().getY() + scene.getY() + SCENE_HEIGHT/2)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The x and y position calculation should consider the sliders layout as well.
I think it should be as:
robot.mouseMove((int)(scene.getWindow().getX() + scene.getX() + slider.getLayoutX() + slider.getLayoutBounds().getWidth()/2),
(int)(scene.getWindow().getY() + scene.getY() + slider.getLayoutY() + slider.getLayoutBounds().getHeight()/2));
and similar change on line 102.
Line 105 would get removed when removing xIncr
(int)(scene.getWindow().getY() + scene.getY() + SCENE_HEIGHT/2)); | ||
}); | ||
|
||
Thread.sleep(3000); // Wait for tooltip to be displayed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sleep
can be removed, The sleep of 1000 ms on line 85 should be sufficient.
I ran by removing this sleep on Mac, Test ran well.
Please check on other platforms.
@arapte , Addressed review comments and added CountDownLatch for tooltip display as discussed. |
@@ -343,6 +343,7 @@ public Object queryAccessibleAttribute(AccessibleAttribute attribute, Object... | |||
}; | |||
thumb.getStyleClass().setAll("thumb"); | |||
thumb.setAccessibleRole(AccessibleRole.THUMB); | |||
dragStart = new Point2D(thumb.getLayoutX(), thumb.getLayoutY()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
dragStart
should be the exact mouse position where mouse pressed has occurred.
With this change mouse gets moved to the layout X, Y position of thumb, even though the mouse press occurred at any other location inside the thumb.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change makes sure that dragStart
is not null when setOnMouseDragged
event handler is called.
As suggested in the issue, I tried to initialize dragStart
in layoutChildren
method but it was causing side effects.
I checked for other event handlers such as onDragDetected
and onMouseDragEntered
, but none of these event handlers were invoked. Looks like these events are also consumed by tooltip similar to how it consumes setOnMousePressed
.
I haven't seen above mentioned side effect while checking the fix. I will check again.
@@ -389,6 +390,19 @@ public Object queryAccessibleAttribute(AccessibleAttribute attribute, Object... | |||
cur.getX() - dragStart.getX() : -(cur.getY() - dragStart.getY()); | |||
behavior.thumbDragged(me, preDragThumbPos + dragPos / trackLength); | |||
}); | |||
|
|||
thumb.setOnMouseEntered(me -> { | |||
if (getSkinnable().getTooltip() != null && getSkinnable().getTooltip().isAutoHide()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I may suggest an edit in these two event handlers - create a local variable:
Tooltip t = getSkinnable().getTooltip();
if (t != null && t.isAutoHide()) {
tooltipConsumeAutoHidingEvents = t.getConsumeAutoHidingEvents();
t.setConsumeAutoHidingEvents(false);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, since the reason for this change is not immediately obvious, I'd add a comment explaining why (perhaps above tooltipConsumeAutoHidingEvents declaration, line 64?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added above suggested edit and added comments
tests/system/src/test/java/test/robot/javafx/scene/SliderTooltipNPETest.java
Show resolved
Hide resolved
@aghaisas @karthikpandelu : |
I do not have a touchscreen machine as well. |
I tested the program provided in JDK-8190411 with touch based Windows system. The proposed fix fixes the issue. For JDK-8293916
My take is on this is - we need to close JDK-8293916 as "incomplete" till a reproducible sample is provided. |
Please enable github actions, so the unit tests can be run automatically. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than my general concern about not setting the value of a property that is under app control, this looks like it will work, unless the app binds to the property. See my comment inline.
modules/javafx.controls/src/main/java/javafx/scene/control/skin/SliderSkin.java
Show resolved
Hide resolved
Hi All, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
@@ -407,7 +407,7 @@ public Object queryAccessibleAttribute(AccessibleAttribute attribute, Object... | |||
|
|||
thumb.setOnMouseExited(me -> { | |||
Tooltip t = getSkinnable().getTooltip(); | |||
if (t != null && t.isAutoHide()) { | |||
if (t != null && t.isAutoHide() && !t.consumeAutoHidingEventsProperty().isBound()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think a second property or a boolean might be better. What if the app code binds autoHidingEventsProperty after onMouseEntered? I know this is highly unlikely, but there is a potential.
At the same time, I think we should proceed with this fix as it addresses a problem which occurs always.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Let's file a follow-on bug to consider the larger question of whether we should change the default value of consumeAutoHidingEventsProperty
for Tooltip, so that they will not consume auto-hiding events by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have filed JDK-8298529 for this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fix looks good to me. Please give @arapte time to comment on this, since he had raised earlier concerns.
@@ -407,7 +407,7 @@ public Object queryAccessibleAttribute(AccessibleAttribute attribute, Object... | |||
|
|||
thumb.setOnMouseExited(me -> { | |||
Tooltip t = getSkinnable().getTooltip(); | |||
if (t != null && t.isAutoHide()) { | |||
if (t != null && t.isAutoHide() && !t.consumeAutoHidingEventsProperty().isBound()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. Let's file a follow-on bug to consider the larger question of whether we should change the default value of consumeAutoHidingEventsProperty
for Tooltip, so that they will not consume auto-hiding events by default.
@karthikpandelu This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been 19 new commits pushed to the
As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details. As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@arapte, @andy-goryachev-oracle, @kevinrushforth) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me too.
/integrate |
@karthikpandelu |
/sponsor |
Going to push as commit 8763e8b.
Your commit was automatically rebased without conflicts. |
@arapte @karthikpandelu Pushed as commit 8763e8b. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
Cause: When slider is dragged for first time after tooltip appears, setOnMousePressed event was not invoked, hence dragStart was null in the subsequently invoked event handler (setOnMouseDragged).
Fix: Initialized dragStart in initialize method.
Test: Added system test to validate the fix.
Note: Initializing dragStart in layoutChildren method as suggested in the bug was causing side effects. Hence initialized dragStart in initialize method.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx pull/965/head:pull/965
$ git checkout pull/965
Update a local copy of the PR:
$ git checkout pull/965
$ git pull https://git.openjdk.org/jfx pull/965/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 965
View PR using the GUI difftool:
$ git pr show -t 965
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/965.diff