Bug #4626

WAbstractItemView selection regression

Added by Bruce Toll about 6 years ago. Updated over 5 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


There appear to be some minor regressions in selection handling with Wt 3.3.5-rc2:

  1. With the ExtendedSelection mode, with multiple rows selected, it is no longer possible to clear the selected rows by clicking on a row that is already selected. This can be observed with the Virtual Scrolling example at NOTE: The selection can be cleared by clicking a row that is not currently selected.
  2. The SelectedClicked editTrigger no longer requires that a row be selected before a click will open an editor. Instead, the behavior is more like the SingleClicked mode and one click both selects a row and opens the editor. This can be demonstrated with a small patch to examples/charts/ChartsExample.C (attached).

It seems that these issues were introduced with modifications in github commit fd45eb4 to WAbstractItemView.C. A temporary work-around is to revert those changes, although it will at minimum impact #469.



Updated by Koen Deforche about 6 years ago

  • Status changed from New to Feedback

Hey Bruce,

The first change is a "known" side effect of the decisions made for implementing #469: we now select on 'mousedown' to be able to handle selection+drag start together. We realize it's a behavioral change, but it's something a user can live with? I see now that other toolkits (such as Mac OSX) would in this case delay the 'deselect' with about a second to make sure it's not a drag start. I'm not sure if this is actually a good UX decision?

The second issues is indeed a bug, a logical consequence of the change that we didn't consider. I've got a fix ready for this.


Updated by Bruce Toll about 6 years ago

Hey Koen,

Thanks for following-up on this issue. I agree with you that the recent change to selection behavior is acceptable for many use cases, and possibly preferable for some, where it could reduce the likelihood of accidentally losing a selection built-up with ctrl-click. "Clear" functionality can easily be provided in an alternative way. For instance, in the case that prompted the issue report, a user has additional "clear all" and "select all" options.

That said, I think the previous select/clear behavior is probably closer to what most users are familiar with outside of Wt. Your comments about OS X prompted me to spend some time looking at the rebranded Thunderbird on Debian Linux (Icedove), as it provides the drag/drop interface that I use the most. From observation, it appears that Thunderbird assumes that a mousedown is starting a click until there is some mouse movement - at which point it provides a drag cursor. Timing does not seem to be a factor in making the determination.

I also found a discussion on stackoverflow that discusses implementing behavior similar to that observed in Thunderbird: I'm not sure how practical/desirable this approach would be in the Wt environment, but if you end up making any changes, I'd be happy to assist with testing.




Updated by Bruce Toll almost 6 years ago

Hey Koen,

I had some more time to look into this and I've attached a patch for your review that largely restores the previous "ClearAndSelect" behavior on clicks in extended selection mode. There are comments on the patch, which has been lightly tested with the treeview-dragdrop example. It's a small patch, but it would definitely benefit from a more thorough review. One concern is whether delayedClearAndSelectIndex_ could ever be used with a stale value.




Updated by Bruce Toll almost 6 years ago

I believe that the previous patch is potentially unsafe if a post() or other update affecting the model/view occurs while the mouse button is down. I'll submit an updated patch that invalidates the stored delayedClearAndSelectIndex_ in WAbstractItemView::setModel.

That still leaves the possibility that the row/column stored at mousedown may reference another element, or point outside the model, when the click is handled. However, it seems that the selection code is designed to handle this situation without error?


Updated by Bruce Toll almost 6 years ago

An updated patch for the github version of Wt (3.3.5-6-g56eecbd) is attached. This version invalidates the stored index as described in the previous comment and also corrects the test for whether a drag has occurred. The patch was lightly tested with the treeview-dragdrop example, where I think it combines the desired drag behavior with the ability to clear/select when not dragging. As noted above, the patch would certainly benefit from additional review.


Updated by Koen Deforche almost 6 years ago

  • Status changed from Feedback to Resolved
  • Assignee set to Koen Deforche
  • Target version set to 3.3.6

Nice! It makes me wonder why I decided that both old and new behaviour couldn't be reconciled, but it's likely that I simply didn't reflect enough.


Updated by Koen Deforche over 5 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF