netbeans icon indicating copy to clipboard operation
netbeans copied to clipboard

[NETBEANS-5728] Fix spurious selections during drag and drop in ETable/OutlineView

Open eirikbakke opened this issue 2 years ago • 5 comments

In an OutlineView with multiple selection enabled, if the user tries to drag one row to a different position (e.g. to reorder rows when the underlying nodes support it), additional rows will be selected as the mouse moves over them during the drag operation. On MacOS, it happens 100% of the time. On Windows, I've seen this bug happen in the past as well, though much less frequently. On Windows the bug is merely annoying, but on MacOS the bug makes OutlineView's drag-and-drop feature unusable.

To reproduce the bug (confirmed to be still present on NetBeans 16 on MacOS):

  1. One place in the IDE where the OutlineView is used is the "Search Results" tab. While this node tree doesn't really support reordering results, the OutlineView can still be used to exhibit the bug. Open some project, right-click the project node, click "Find..." and search for something that will bring up multiple (~5 or more) results.
  2. Drag the first result row a couple of rows down, holding the left mouse button down to observe the bug. If the bug does not appear, let go and try again until it does. On Windows, you may need to start dragging from the lower part of the row you're trying to drag, and the dragged mouse cursor may need to exit onto the next row within a certain time period from when the left mouse button was pressed. On MacOS, the bug happens every time, regardless of how long I wait hovering over the original row while holding down the mouse button before beginning to drag across other rows.

See my original ancient issue description from 2013 and the more recent NETBEANS-5728.

This PR adds a workaround in ETable, the component used by OutlineView. This PR also fixes a bug where dragging outside the ETable may cause Swing's autoscrolling events to continue firing indefinitely. The patch has worked successfully in my NetBeans Platform application Ultorg for 1.5 years.

eirikbakke avatar Jan 20 '23 22:01 eirikbakke

Yeah, it's ugly. It's been a while since I worked on this, but I seem to remember trying various approaches, including subclassing BasicTableUI, and concluding the stack trace approach was the lowest-risk way to fix it.

I hadn't seen the StackWalker API before; does it have advantages over Exception.getStackTrace?

eirikbakke avatar Feb 11 '23 16:02 eirikbakke

Tried this. Works fine regarding "selection avoidance", but have the feeling that autoscrolling works not as good as before.

Have running two NB instances side-by-side (NB 16 from DMG and compiled master branch; on macOS). Autoscrolling works pretty reliable in NB 16, but in the version with this PR, it often does not autoscroll. Seems to depend on how fast I move the mouse out of the table...

Have tried a different solution:

  • removed mouseDragged listener that invokes scrollRectToVisible()
  • added following code from JTable.changeSelection() into "veto return" block in ETable.changeSelection()

I think this works a little bit better, but not as reliable as before. Don't know why 😕

Anyway, for compatibility, I would move autoscrolling to ETable.changeSelection() as done in super.changeSelection(). This also avoids an additional listener and a possible side-effect of always scrolling while dragging.

DevCharly avatar Feb 14 '23 13:02 DevCharly

I hadn't seen the StackWalker API before; does it have advantages over Exception.getStackTrace?

It should be faster: https://www.sitepoint.com/deep-dive-into-java-9s-stack-walking-api/ But don't think that this would make a difference because it is not invoked very often here.

I'm using StackWalker in FlatLaf for similar purposes here: StackUtilsImpl for Java 9+ Here is StackUtilsImpl for Java 8 and base class StackUtils

DevCharly avatar Feb 14 '23 13:02 DevCharly

Update: just tried a DEV build without this PR, and autoscrolling is also not as reliable as in NB 16 😕

Selection-while-dragging also behaves slightly different (in Search results view):

  • in NB 16, rows under mouse are selected immediately
  • in DEV build, there is some delay and not all rows are selected

Both NB versions use same Java 11 VM. Maybe this is a issue on my machine. Or NB DEV build is started with different options than installed NB 16. Or something else changed in NB 17... BTW I've not checked out the commit of this PR. I'm on latest master and cherry picked this PR

Is there a DMG of NB 17rc available anywhere?

DevCharly avatar Feb 14 '23 13:02 DevCharly

@DevCharly you'll have to use the zip at https://nightlies.apache.org/netbeans/candidate/netbeans/ There are unsigned installers for other platforms but not a DMG.

neilcsmith-net avatar Feb 14 '23 14:02 neilcsmith-net