Bug #4749
closedWTreeView, doubleClicked does not work like it did in Wt-3.3.4 if SingleSelection is enabled
0%
Description
The doubleClicked event of WTreeView behaves differently in Wt-3.3.5 than it did in Wt-3.3.4.
If you run the attached example with Wt-3.3.4 you can double click any item and the popup will show.
With Wt-3.3.5 the double click event does not work until the item is selected.
Once the item is selected the double click works and the popup shows.
Files
Updated by Koen Deforche about 8 years ago
- Status changed from New to Feedback
That's indeed a change in behavior that we didn't document in the release notes, but it's a consequence of modifying the selection on mouse-went-down instead of mouse-click. We cannot revert this change as it's what enables the select&drag to work, while previously a user would first have to select an item and could then only start dragging (#469). But if you prefer we could perhaps make this somehow an optional setting (that selection works with click rather than mouse-down) ?
Updated by Markus S about 8 years ago
Koen Deforche wrote:
That's indeed a change in behavior that we didn't document in the release notes, but it's a consequence of modifying the selection on mouse-went-down instead of mouse-click. We cannot revert this change as it's what enables the select&drag to work, while previously a user would first have to select an item and could then only start dragging (#469). But if you prefer we could perhaps make this somehow an optional setting (that selection works with click rather than mouse-down) ?
Thank you for the quick response!
If the old behaviour could be enabled with an optional setting that would be great. It is hard to explain why a user should select an item before he can open it with a double click. How long will it take to change this?
Updated by Koen Deforche about 8 years ago
Reflecting a bit more, I tested your example with 3.3.4 and notice that also there a double click will immediately trigger the popup. The only difference is that in 3.3.4 the selection is not affected (because a double click means there's no single click), but in 3.3.5, the selection is changed at the same time. Are you observing something different then?
Updated by Max Quatember about 8 years ago
Hi Koen,
We are observing following with the sent testcase:
In wt-3.3.5 doubleclicking a treeview-item only selects it but does not trigger the popup!
(Resources are updated correctly...)
best regards,
Max
Updated by Koen Deforche about 8 years ago
- Assignee set to Koen Deforche
Hey Max,
That might be correct. There were fixes to make the behaviour more backwards compatible that were later added to Wt 3.3.5, and that could explain the discrepancy seen.
Can you see if the following git version works fine:
95d4917fbeb119d88f5696198eac9c9a6fdc8675
(You could also try the latest master but we've just merged in several branches for new features we would like in Wt 3.3.6, so there may be issues, like building with MSVC :-) )
Koen
Updated by Max Quatember about 8 years ago
Hi Koen!
I tried your mentioned git version and latest git master, both have the same behaviour for me...
What can we do next?
(fyi latest git master + boost 1.60 compile fine with msvc 2015 update 1 ;-))
Max
Updated by Koen Deforche about 8 years ago
Hey Max,
That's really odd. I double checked again, to make sure, and describe how the test case behaves for me. Double click results in the item being selected (because of the mouse down) and the popup being shown (because of the double click). I tried on linux, using chrome and firefox. I can ask Wim to check this with a MSVC build?
Koen
Updated by Koen Deforche about 8 years ago
- Assignee changed from Koen Deforche to Wim Dumon
Updated by Max Quatember about 8 years ago
Hi Koen, hi Wim,
We just checked with Fedora/Firefox and Win10/Chrome.
It seems that it has something to do with the speed of the doubleklick. On Windows I have to be very very fast that the doubleclick gets recognized.
On Linux I don't have to be that fast, but a "slow" doubleclick also do't get recognized.
Best regards,
max
Updated by Max Quatember about 8 years ago
Please forget the latest update:
After testing Linux and Windows:
Firefox:
OK on Windows
OK on Linux.
Chrome:
NOT OK on Windows (Windows 10, Chrome Version 48.0.2564.116 m)
Cannot test on Linux
Thanks for the patience!
Best regards,
Max
Updated by Wim Dumon about 8 years ago
- Assignee changed from Wim Dumon to Koen Deforche
Updated by Koen Deforche about 8 years ago
- Status changed from Feedback to InProgress
I think I know what's going on. It's an issue we've seen in the past: on some browsers/platforms, the event handling is being disturbed/interrupted by a DOM update. In this case, the first (or second) click isn't being registered because in response to the mouse down we updated the item. We will try to reproduce and find a workaround.
Updated by Koen Deforche about 8 years ago
- Status changed from InProgress to Resolved
Updated by Max Quatember about 8 years ago
Hi Koen!
Just pulled latest git.
Everything works fine again!
Tested: Win 10 with Chrome and Firefox, Fedora with Chrome + Firefox.
Thank you very much!
best regards,
Max
Updated by Koen Deforche almost 8 years ago
- Status changed from Resolved to Closed
- Target version changed from 3.3.5 to 3.3.6