-
Notifications
You must be signed in to change notification settings - Fork 461
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
8296409: Multiple copies of accelerator change listeners are added to MenuItems, but only 1 is removed #937
Conversation
👋 Welcome back dwookey! A progress list of the required criteria for merging this PR into |
I wonder if changes in JDK-8295426: MenuButtonSkin: memory leak when changing skin would impact this PR or vice versa. PR: #919 |
@DeanWookey : the newly added test still fails with JDK-8295426 changes, so I think we might want to address/integrate this PR first. |
Reviewers: @arapte @andy-goryachev-oracle |
|
||
List<Mnemonic> mnemonics = new ArrayList<>(); | ||
sceneChangeListener = (scene, oldValue, newValue) -> { | ||
if (oldValue != null) { | ||
ControlAcceleratorSupport.removeAcceleratorsFromScene(getSkinnable().getItems(), oldValue); |
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.
will it handle a case where the menu button gets attached to a different scene?
could you add a second test for this scenario please?
And i wonder if the problem is in ControlAcceleratorSupport rather than here. We do have a similar code in Control:380, do we have a problem there?
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 code in ControlAcceleratorSupport adds its own scene listeners for each node added. MenuButtonSkinBase does the same, unlike Control which only calls it once.
I think we could fix it in ControlAcceleratorSupport alternatively or in addition to this fix. The code in ControlAcceleratorSupport appears to do everything this would've done.
I've added the test for changing scenes.
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.
Here is an alternative fix: 80971d8
I just reverted the MenuButtonSkinBase changes. The tests pass with this fix, or with both.
I'm a little more nervous about that one because I had to remove the code that removed and then added a scene listener. I'm not sure why it was done because the listener is independent of a specific scene.
Basically, that fix only does the install if the install wasn't already done on that anchor meaning it can get called any number of times safely stopping duplicate accelerators being added.
I would go with either both fixes together, or just the MenuButtonSkinBase one.
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.
please forgive me - it might take me a bit longer to review.
@kevinrushforth, @arapte I clicked the request review on andy and it removed arapte for some reason. I guess that button shouldn't be clicked. Oops. |
That seems like a GitHub UI problem. I'll re-request a review from @arapte |
@DeanWookey : Also, would it be possible to base your changes on top of #919 since the skin got reworked to eliminate a memory leak, and it might be easier to base your changes on top of that rather than try to resolve non-trivial merge conflicts. What do you think? |
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.
change requested:
- use alternative code
- base on top of 8295426: MenuButtonSkin: memory leak when changing skin #919
Doing this makes it harder for reviewers to see what is actually being changed. Unless / until we enable the Skara support for dependent PRs (which the |
This is true, but it will the actual review process (especially, testing) move faster. Or, we can wait for #919 to get integrated first. edit: I want to avoid non-trivial merges, they are harder to deal with than just ignoring changes from another PR. |
Probably better to just wait then. |
Now that #919 is integrated, the conflict needs to be resolved. |
# Conflicts: # modules/javafx.controls/src/main/java/javafx/scene/control/skin/MenuButtonSkinBase.java
I've put the alternative fix in on top of the latest changes. Sorry it took so long. |
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 much leaner now, thanks!
@DeanWookey 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 7 new commits pushed to the
Please see this link for an up-to-date comparison between the source branch of this pull request and the 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 (@andy-goryachev-oracle, @arapte) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
/integrate |
@DeanWookey |
/sponsor |
Going to push as commit bac8ee8.
Your commit was automatically rebased without conflicts. |
@arapte @DeanWookey Pushed as commit bac8ee8. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
When menu buttons are added and removed from the scene, an accelerator change listener is added to each menu item in the menu. There is nothing stopping the same change listener being added multiple times.
MenuButtonSkinBase calls the ControlAcceleratorSupport.addAcceleratorsIntoScene(getSkinnable().getItems(), getSkinnable()); method each time the button is added to the scene, but that method itself also registers a listener to call itself. Each time the button is added to the scene, the method is called at least twice.
When it's removed from the scene, the remove accelerator method is also called twice, but only the first call removes a change listener attached to the accelerator because the first call removes the entry from the hashmap changeListenerMap. The second call finds nothing in the map, and doesn't remove the additional instance.
This pull request just removes the redundant code in the MenuButtonSkinBase.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx pull/937/head:pull/937
$ git checkout pull/937
Update a local copy of the PR:
$ git checkout pull/937
$ git pull https://git.openjdk.org/jfx pull/937/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 937
View PR using the GUI difftool:
$ git pr show -t 937
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/937.diff