Skip to content
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

Closed
wants to merge 9 commits into from

Conversation

karthikpandelu
Copy link
Member

@karthikpandelu karthikpandelu commented Dec 1, 2022

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

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

Issue

  • JDK-8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true

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

@bridgekeeper
Copy link

bridgekeeper bot commented Dec 1, 2022

👋 Welcome back karthikpandelu! 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 openjdk bot added the rfr Ready for review label Dec 2, 2022
@mlbridge
Copy link

mlbridge bot commented Dec 2, 2022

Webrevs

Copy link
Member

@arapte arapte left a 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.

Comment on lines 67 to 78
public static void main(String[] args) {
initFX();
try {
SliderTooltipNPETest test = new SliderTooltipNPETest();
test.testSliderTooltipNPE();
} catch (Throwable e) {
e.printStackTrace();
} finally {
exit();
}
}

Copy link
Member

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 {
Copy link
Member

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.

Comment on lines 88 to 89
robot.mouseMove((int)(scene.getWindow().getX() + scene.getX() + SCENE_WIDTH/2),
(int)(scene.getWindow().getY() + scene.getY() + SCENE_HEIGHT/2));
Copy link
Member

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
Copy link
Member

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.

@karthikpandelu
Copy link
Member Author

@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());
Copy link
Member

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.

Copy link
Member Author

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()) {
Copy link
Contributor

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);
            }

Copy link
Contributor

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?)

Copy link
Member Author

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

@andy-goryachev-oracle
Copy link
Contributor

@aghaisas @karthikpandelu :
could you guys check if this change fixes JDK-8293916 ?
I don't have a touchscreen machine here, and these two bugs seem related.

@karthikpandelu
Copy link
Member Author

I do not have a touchscreen machine as well.
@aghaisas please check if bug given above is fixed.

@aghaisas
Copy link
Collaborator

aghaisas commented Dec 6, 2022

@aghaisas please check if bug given above is fixed.

I tested the program provided in JDK-8190411 with touch based Windows system. The proposed fix fixes the issue.

For JDK-8293916

  1. The bug does not have a reproducible test program.
  2. It is reported that the bug does not occur on Windows system - and - I have a touch based Windows system.
  3. It is reported that the bug is observed without ToolTip. This indicates that there exists another path to the reported NPE.

My take is on this is - we need to close JDK-8293916 as "incomplete" till a reproducible sample is provided.

@andy-goryachev-oracle
Copy link
Contributor

Pre-submit test status Skipped — Testing is not configured

Please enable github actions, so the unit tests can be run automatically.

Copy link
Member

@kevinrushforth kevinrushforth left a 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.

@karthikpandelu
Copy link
Member Author

Hi All,
All the changes mentioned in the review are now addressed. Please review.

Copy link
Contributor

@andy-goryachev-oracle andy-goryachev-oracle left a 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()) {
Copy link
Contributor

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.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Contributor

@andy-goryachev-oracle andy-goryachev-oracle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

Copy link
Member

@kevinrushforth kevinrushforth left a 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()) {
Copy link
Member

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.

@openjdk
Copy link

openjdk bot commented Dec 10, 2022

@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:

8190411: NPE in SliderSkin:140 if Slider.Tooltip.autohide is true

Reviewed-by: arapte, angorya, kcr

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 master branch:

  • dadfcaf: 8295339: DatePicker updates its value property with wrong date when dialog closes
  • 9f6ec88: 8295755: Update SQLite to 3.39.4
  • c900a00: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize
  • 6abbe08: 8295809: TreeTableViewSkin: memory leak when changing skin
  • 07e693b: 8245145: Spinner: throws IllegalArgumentException when replacing skin
  • 5b0d3b5: 8296621: Stage steals focus on scene change
  • f96b350: 8296854: NULL check of CTFontCopyAvailableTables return value is required
  • 6f36e70: 8295175: SplitPaneSkin: memory leak when changing skin
  • bb13920: 8295531: ComboBoxBaseSkin: memory leak when changing skin
  • f333662: 8297413: Remove easy warnings in javafx.graphics
  • ... and 9 more: https://git.openjdk.org/jfx/compare/0a785ae036f48c736b65df865a3b93f954d46fe5...master

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 /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

@openjdk openjdk bot added the ready Ready to be integrated label Dec 10, 2022
Copy link
Member

@arapte arapte left a 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.

@karthikpandelu
Copy link
Member Author

/integrate

@openjdk openjdk bot added the sponsor Ready to sponsor label Dec 12, 2022
@openjdk
Copy link

openjdk bot commented Dec 12, 2022

@karthikpandelu
Your change (at version 883fcf5) is now ready to be sponsored by a Committer.

@arapte
Copy link
Member

arapte commented Dec 12, 2022

/sponsor

@openjdk
Copy link

openjdk bot commented Dec 12, 2022

Going to push as commit 8763e8b.
Since your change was applied there have been 19 commits pushed to the master branch:

  • dadfcaf: 8295339: DatePicker updates its value property with wrong date when dialog closes
  • 9f6ec88: 8295755: Update SQLite to 3.39.4
  • c900a00: 8289357: (Tree)TableView is null in (Tree)TableRowSkin during autosize
  • 6abbe08: 8295809: TreeTableViewSkin: memory leak when changing skin
  • 07e693b: 8245145: Spinner: throws IllegalArgumentException when replacing skin
  • 5b0d3b5: 8296621: Stage steals focus on scene change
  • f96b350: 8296854: NULL check of CTFontCopyAvailableTables return value is required
  • 6f36e70: 8295175: SplitPaneSkin: memory leak when changing skin
  • bb13920: 8295531: ComboBoxBaseSkin: memory leak when changing skin
  • f333662: 8297413: Remove easy warnings in javafx.graphics
  • ... and 9 more: https://git.openjdk.org/jfx/compare/0a785ae036f48c736b65df865a3b93f954d46fe5...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Dec 12, 2022
@openjdk openjdk bot closed this Dec 12, 2022
@openjdk openjdk bot removed ready Ready to be integrated rfr Ready for review sponsor Ready to sponsor labels Dec 12, 2022
@openjdk
Copy link

openjdk bot commented Dec 12, 2022

@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.

@karthikpandelu karthikpandelu deleted the slider_npe_fix branch December 12, 2022 06:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated
Development

Successfully merging this pull request may close these issues.

5 participants