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

8265206: Tree-/TableCell: editing state not updated on cell re-use #473

Closed
wants to merge 2 commits into from

Conversation

kleopatra
Copy link
Collaborator

@kleopatra kleopatra commented Apr 21, 2021

Issue is missing update of Tree-/TableCell's editiable state when changing its index from editingIndex to -1.

Seems to be a left-over from fixing cell's editing update - done in JDK-8150525 - on index change for the special case of new index -1.

Fixed by cleaning out editing state in that corner case also, added tests that were failing before and passing after the fix. Note that there are also tests that passed before: the previous fix didn't add any tests, so added them here.


Progress

  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change must be properly reviewed

Issue

  • JDK-8265206: Tree-/TableCell: editing state not updated on cell re-use

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jfx pull/473/head:pull/473
$ git checkout pull/473

Update a local copy of the PR:
$ git checkout pull/473
$ git pull https://git.openjdk.java.net/jfx pull/473/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 473

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jfx/pull/473.diff

@bridgekeeper
Copy link

bridgekeeper bot commented Apr 21, 2021

👋 Welcome back fastegal! 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 Apr 21, 2021
@mlbridge
Copy link

mlbridge bot commented Apr 21, 2021

Webrevs

@kevinrushforth
Copy link
Member

kevinrushforth commented Apr 21, 2021

/reviewers 2

@openjdk
Copy link

openjdk bot commented Apr 21, 2021

@kevinrushforth
The number of required reviews for this PR is now set to 2 (with at least 1 of role reviewers).

// cancelEdit method would do. Yet, I need to call cancelEdit
// so that subclasses which override cancelEdit can execute. So,
// I have to use a kind of hacky flag workaround.
updateEditingIndex = false;
Copy link
Collaborator

@johanvos johanvos Apr 21, 2021

Choose a reason for hiding this comment

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

Do you need to assert on updateEditingIndex being true before this is done?

Copy link
Collaborator Author

@kleopatra kleopatra Apr 21, 2021

Choose a reason for hiding this comment

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

hmm .. don't quite understand your comment: it's a flag to tell cancelEdit to not update control's editing state (that whole block is simply extracted from the pre-fix state .. where it has been for ages ;) So the answer is most probably no :)

Copy link
Collaborator

@johanvos johanvos Apr 21, 2021

Choose a reason for hiding this comment

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

I see the updateEditingIndex is used as a hacky flag as the comment says, and table.edit(-1, null) is called conditionally.
But my question is about the pre- and postconditions. What would happen if a subclass overrides cancelEdit and throws an exception, so that updateEditingIndex = true is not called after the cancelEdit? In that case, updateEditingIndex stays false.
I'm not saying this is an issue, just wondering about this as this flag does an important thing -- and I do know this was in the code before the PR, so the PR is definitely an improvement, I'm just thinking that this might be an opportunity to deal with the precondition that updateEditingIndex should be true when entering the method and false when leaving the method.

Copy link
Collaborator Author

@kleopatra kleopatra Apr 22, 2021

Choose a reason for hiding this comment

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

thanks for the explanation and spelling it out to me :)

But my question is about the pre- and postconditions. What would happen if a subclass overrides cancelEdit and throws an exception, so that updateEditingIndex = true is not called after the cancelEdit? In that case, updateEditingIndex stays false.

talking about pre/postCondiditions: wouldn't an override of cancelEdit (and the other editing life-cycle methods) that's throwing an exception violate its contract? Don't see any constraints in its spec at Cell, so I would say it must do it's very best not to throw anything, at least not intentionally. And if it happens somewhere along the chain, f.i. an edit handler going wild, then it would be the responsibility of that handler to behave (aka: usage error except for the little bugs in the editEvents .. ).

I'm not saying this is an issue, just wondering about this as this flag does an important thing -- and I do know this was in the code before the PR, so the PR is definitely an improvement, I'm just thinking that this might be an opportunity to deal with the precondition that updateEditingIndex should be true when entering the method and false when leaving the method.

hmm .. again not quite sure I understand: shouldn't updateEditingIndex be true both on entering and leaving doCancelEdit?. Anyway, if there's something going wrong in cancelEdit, the cell is in an arbitrary state: could still be editing (if the wrong-going happened before calling cell.cancelEdit) or not, could have fired the cancel event or not, could have updated its visuals or not .. there's not much we can do to recover from it. When going from this undeterminate state into the next editing cycle the outcome is .. unpredictable.

All that said: we could wrap the flag un-/setting into a try-finally block - then at least the whacky flag is in a specific state after all hell broke loose ..

Copy link
Collaborator

@johanvos johanvos Apr 23, 2021

Choose a reason for hiding this comment

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

I agree a try-finally block here (setting the flag in a specific state) might be useful -- I prefer to keep unpredictable states for quantum computing :)

Copy link
Collaborator Author

@kleopatra kleopatra Apr 23, 2021

Choose a reason for hiding this comment

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

done for Tree/TableCell:

  • wrapped into try-finally block with resetting updateEditingIndex flag to true in finally
  • added test to Tree/TableCellTest that fails before and passes after the change

now the flag is more predictable than the behavior of extending classes' cancelEdit implementations (and states in quantum computing - probably, your book is still on my reading list :)

@kevinrushforth kevinrushforth requested a review from aghaisas Apr 22, 2021
@openjdk
Copy link

openjdk bot commented Apr 29, 2021

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

8265206: Tree-/TableCell: editing state not updated on cell re-use

Reviewed-by: aghaisas, jvos

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 14 new commits pushed to the master branch:

  • 0a68613: 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop
  • cc70cdf: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners
  • 33bbf3f: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene
  • 483f171: 8264677: MemoryLeak: Progressindicator leaks, when treeShowing is false
  • 6b63bf5: 8265669: AccumCell should not be visible
  • ed080c8: 8262276: Debug build of WebKit fails
  • db30e71: 8265513: Openjfx graphics build broken (Eclipse)
  • b50ce94: 8264952: [TestBug] Controls unit tests - ControlTest and SpinnerTest fail for non US Locale
  • 27e57d3: 8265469: Allow to build media and webkit for Linux-AArch64
  • dfda00d: 8265514: Openjfx controls running tests broken (Eclipse)
  • ... and 4 more: https://git.openjdk.java.net/jfx/compare/86b854dc367fb32743810716da5583f7d59208f8...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.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Ready to be integrated label Apr 29, 2021
@kleopatra
Copy link
Collaborator Author

kleopatra commented Apr 29, 2021

/integrate

@openjdk openjdk bot closed this Apr 29, 2021
@openjdk openjdk bot added integrated Pull request has been integrated and removed ready Ready to be integrated rfr Ready for review labels Apr 29, 2021
@openjdk
Copy link

openjdk bot commented Apr 29, 2021

@kleopatra Since your change was applied there have been 14 commits pushed to the master branch:

  • 0a68613: 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop
  • cc70cdf: 8258777: SkinBase: add api to un-/register invalidation-/listChange listeners
  • 33bbf3f: 8263402: MemoryLeak: Node hardreferences it's previous Parent after csslayout and getting removed from the scene
  • 483f171: 8264677: MemoryLeak: Progressindicator leaks, when treeShowing is false
  • 6b63bf5: 8265669: AccumCell should not be visible
  • ed080c8: 8262276: Debug build of WebKit fails
  • db30e71: 8265513: Openjfx graphics build broken (Eclipse)
  • b50ce94: 8264952: [TestBug] Controls unit tests - ControlTest and SpinnerTest fail for non US Locale
  • 27e57d3: 8265469: Allow to build media and webkit for Linux-AArch64
  • dfda00d: 8265514: Openjfx controls running tests broken (Eclipse)
  • ... and 4 more: https://git.openjdk.java.net/jfx/compare/86b854dc367fb32743810716da5583f7d59208f8...master

Your commit was automatically rebased without conflicts.

Pushed as commit ccf51e4.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@kleopatra kleopatra deleted the bug-fix-8265206 branch Apr 29, 2021
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
4 participants