-
Notifications
You must be signed in to change notification settings - Fork 512
8207333: [Linux, macOS] Column sorting is triggered always after context menu request on table header #1754
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
base: master
Are you sure you want to change the base?
Conversation
👋 Welcome back jpereda! A progress list of the required criteria for merging this PR into |
❗ This change is not yet ready to be integrated. |
Webrevs
|
I'll take a look. |
I can only test it on macOS and Windows. Could someone with a linux system help please? |
@andy-goryachev-oracle |
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.
thank you for fixing this bug, @jperedadnr !
testing with the monkey tester looks good on macOS 15.3.2 and windows 11.
@Ziad-Mid could you be the second reviewer? |
I can't test on Linux , I will check same for macOS |
@@ -243,6 +245,7 @@ public TableColumnHeader(final TableColumnBase tc) { | |||
} | |||
|
|||
if (me.isConsumed()) return; | |||
popupTriggeredOnMousePressed = me.isPopupTrigger(); | |||
me.consume(); | |||
|
|||
header.getTableHeaderRow().columnDragLock = true; |
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.
On Mac a context menu can be invoked using the right button or the left button in conjunction with the Control key. In the second case the pop trigger flag will be set and the primary button will be down. If I'm reading the code correctly this could get the header stuck in column re-ordering mode.
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.
Testing on macOS 15.3.2, it does not get stuck when using control+left-click, works as expected.
There is one (existing and unrelated) problem - if the user tries to dismiss the popup menu by clicking on the header, it dismisses the popup (correctly), but then proceeds to re-sort the table (unexpected).
One can say it works as designed, since the click falls on a header cell and the expected operation is to toggle the sorting, with the side effect of dismissing the popup.
On the other hand, Excel (both mac and windows) behaves differently - a click on the spreadsheet header dismisses the popup and does not select the column, as it normally does when no popup is present.
What do you guys 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.
control+left-click works as expected for me too.
When the context menu is showing, clicking anywhere outside of it, closes the popup (because of the autohide property), but doesn't consume the event. If you click on a button, for instance, it will be fired. In any case, this is the same before and after this PR, so maybe an issue for a later discussion.
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.
definitely an unrelated issue, I just wanted to ask whether you guys think it crosses the threshold for a bug.
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.
control+left-click works as expected for me too.
For control+left-click it looks like the code will call columnReordingStarted
but on the released event it won't call columnReorderingComplete
. I have no idea if this will lead to problems or not.
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.
@beldenfox Do you think we should address that issue (ctrl+left click + columnReordering) in this PR? Else, do we need to do anything else to move it forward?
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.
You should be good with a few tweaks. If the press event is a popup trigger don't set the columnDragLock or call columnReorderingStarted (since you might not get a release event). In the drag handler check popupTriggeredOnMousePressed and do nothing if it's set. Your released handler looks fine as-is. I think that should cover it.
By the way, in a perfect world you would have more predictable behavior. When the popup menu is shown it would grab the mouse pointer and you would never see the release event. That would allow the user to click to bring up the popup and start dragging across the menu items without having to release the mouse.
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.
Thanks, @beldenfox! I've included your suggestions, and also added the ctrl+left click macOS case to the test.
@@ -271,7 +274,10 @@ public TableColumnHeader(final TableColumnBase tc) { | |||
TableColumnHeader header = (TableColumnHeader) me.getSource(); | |||
header.getTableHeaderRow().columnDragLock = 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.
On Ubuntu 22.04 the table column header is not receiving a mouse released event if a context menu is shown. Not sure where the released event is going but it's not to any node on the primary stage. The docs are vague on this but this looks like a separate bug that's making it hard to test this PR.
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.
what happens in the master branch (without this PR's changes)?
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 was having trouble reproducing the original bug on the master branch; the sorting is done when the mouse is released and most of the time that event never arrives (I think it does every now and then).
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 is strange - the bug is immediately apparent. which macOS version do you have? although I don't think the version matters.
I am testing with an external mouse, with control-left-click, and with the double-finger-click gesture on the trackpad.
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 was having problems reproducing on Linux. No problem reproducing on macOS.
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.
On Linux I have some issues too: the test that I attached to the JBS issue doesn't fail for me on Linux, but the test that I added to this PR does fail without the fix.
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.
Can you try the monkey tester? it allows setting properties on the table view / table column at runtime...
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 just verified that on Linux the released event usually goes to the popup window. Basically it's whatever window is under the cursor at the time; if I move the mouse fast enough it may go to a node on the primary stage. I don't think this is our doing, it's how GTK is delivering the event.
On the JavaFX side I'm not sure this counts as a bug. The docs state that entered and released events should arrive in pairs during drag and drop operations but doesn't address this case.
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 Monkey tester app works for me on Linux (Ubuntu 22.04, either mouse or pad), before and after this PR (so I can't reproduce the issue there, as I mentioned, though the test added to the PR fails without the patch).
Some tests in TableColumnHeaderTest are failing in CI. |
Indeed... this test fails: It has this JavaDoc:
This was changed based on @beldenfox suggestion. I'll change it back. |
Tests are green now, except for the Windows one, which fails for the |
much better, thank you. btw, you can re-start failing tasks - I hope it's just an intermittent failure. |
It has failed three times in a row. Most likely this has already been fixed with JDK-8354337, so I'll sync from head. |
It is green now (https://github.com/jperedadnr/jfx/actions/runs/14715013268) after I ran again the failed gradle wrapper validation. |
If the mouse pressed event triggers a context menu you might never see the mouse released event. So you have to consider what it means if column drag lock gets set and then never cleared. The failing test strikes me as odd, it is explicitly testing a bit of internal state to verify that a right-click drag operation will work. Users don't expect this to work and overloading right-click makes life complicated so right-click drags are generally disabled even on Windows. I understand that this test case was added because the table header was getting into a persistent bad state but unless I'm missing something (and I certainly might be) the bug should have been resolved by turning right-click drag into a no-op. (It doesn't help that the test uses the MouseEventFirer which sets the isPopupTrigger flag on both pressed and release which doesn't match the behavior of any platform.) |
I see a difference in behavior between this PR and the master branch. Admittedly, the scenario is weird:
What I sort of expect is the behavior of JTable: the right click completes the drag to reorder gesture. What I see in the master branch is quite weird (testing on macOS): the drag to reorder gesture completes with the column being repositioned, but the popup menu flashes on and then off as the right mouse button is released. With this PR (again, on macOS) the behavior is different: the popup appears, at the same time the dragging continues uninterrupted. On Windows, the position of the highlight indicating the column being dragged jumps to the original place after right mouse button is released. It looks to me as if the original developers did not think of such a scenario (while JTable ones did). We could deal with this scenario in a separate bug, though I think the Windows case needs to be fixed in this PR. Alternatively, we might want to handle this weird scenario in this PR. What do you think? P.S. I can't test on Linux, and we should probably also test in on the latest Ubuntu as it seems to work slightly different? |
@beldenfox I understand your concerns about So I suggest we take this on a follow up issue, revisiting the need to change the lock from true to false when the popup is triggered, and modifying or removing those tests accordingly. What do you think? |
@andy-goryachev-oracle About this edge case, on macOS it seems better behaviour after this PR: before the highlighting jumps unexpectedly, while after it, the highlighted area is updated smoothly. And I don't see the popup flashing. |
My immediate thought was we should finish the drag to reorder gesture and avoid showing the popup if the right mouse button is pressed during the drag operation, regardless of the platform (this will change the behavior but I think it makes more sense). I would recommend doing it as a part of this PR, but it's up to you. Doing this will also avoid the issue we saw on windows where the highlighted column being dragged jumps suddenly to the original position which is simply wrong. What do you think? |
I think this PR should probably be accepted as-is. It fixes an obvious problem and doesn't introduce any new ones. Someone should enter a follow-up PR citing some of the other problems but most of those have been around for years and only affect users who are looking for trouble (most wouldn't even consider using the right mouse button to drag). Here you have separate behavior on click vs drag-click and have to deal with two different approaches to context menus. I've tackled this sort of thing before and it usually takes two or four or six tries to get right. To reduce the complexity you have be aggressive at ignoring irrelevant events (no right-click drag!) and avoid setting up state related to dragging until the user actually starts dragging. So this code needs a modest re-write but, again, it doesn't need to happen in this PR. |
I tend to agree, as long as any remaining problems are preexisting and not likely to be encountered in the primary use case. |
The windows problem is pre-existing. The after-the-fix behavior is slightly better. I'll create the follow-up ticket. |
Note: The JBS issue JDK-8207333 refers to Linux, but it happens on macOS too.
When a TableColumn has a ContextMenu, if the user right clicks on the tableColumnHeader, the ContextMenu shows up, but, as described on the issue, on macOS and Linux, the table gets sorted as well.
Currently,
TableColumnHeader#mouseReleasedHandler
checks forMouseEvent::isPopupTriggered
, but it doesn't have a check onmousePressed
. However, it can be seen that a right click on the header has the following values forMouseEvent:: isPopupTriggered
on the different platforms and mouse pressed and released events:Also, the JavaDoc for
MouseEvent::isPopupTriggered
clearly states that:Therefore, this PR adds a check to
MouseEvent::isPopupTrigger
in the mouse pressed event, that can be used later on to cancel the header sorting when the mouse released event happens.Also a system test has been added. It fails on macOS and Linux, and passes on Windows before this PR, and passes on the three platforms with this PR.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/1754/head:pull/1754
$ git checkout pull/1754
Update a local copy of the PR:
$ git checkout pull/1754
$ git pull https://git.openjdk.org/jfx.git pull/1754/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 1754
View PR using the GUI difftool:
$ git pr show -t 1754
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1754.diff
Using Webrev
Link to Webrev Comment