ListItems with trailing but no leading actions, after swiping right break selectMode
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
ubuntu-ui-toolkit (Ubuntu) |
Fix Released
|
High
|
Zsombor Egri | ||
Vivid |
Fix Committed
|
Undecided
|
Unassigned |
Bug Description
If you have a listitem with trailing actions but no leading actions it is possible to break the selectMode as the press and hold signal is never fired.
Steps with the example QML app [0]
1) Swipe one of the listitems to the right (to try and reveal a leading action [which there aren't any])
2) Press and hold on the swiped listitem
3) Notice nothing happens (also notice nothing in the log for the press and hold appears)
4) Press and hold on another listitem
5) Notice that all but the swiped listitem change to selectMode=True
What was expected:
3) For all of the items to change to selectMode=True
5) For all of the items to change to selectMode=True
Note that you can 'fix' the listitem by swiping to the left and clicking on an action or dismissing the swipe, then you are able to press and hold it to activate selectMode correctly again.
Related branches
- PS Jenkins bot: Approve (continuous-integration)
- Ubuntu SDK team: Pending requested
-
Diff: 179 lines (+157/-3)2 files modifiedmodules/Ubuntu/Components/plugin/uclistitem.cpp (+6/-3)
tests/unit_x11/tst_components/tst_listitem_actions_breaks_selectmode.qml (+151/-0)
description: | updated |
summary: |
- ListItems with trailing but no leading, after swiping right break - selectMode + ListItems with trailing but no leading actions, after swiping right + break selectMode |
Changed in ubuntu-ui-toolkit (Ubuntu): | |
assignee: | nobody → Zsombor Egri (zsombi) |
tags: | added: new-listitem |
Changed in ubuntu-ui-toolkit (Ubuntu): | |
importance: | Undecided → High |
status: | Confirmed → In Progress |
Changed in ubuntu-ui-toolkit (Ubuntu): | |
status: | In Progress → Fix Committed |
Changed in ubuntu-ui-toolkit (Ubuntu Vivid): | |
status: | New → Fix Committed |
Status changed to 'Confirmed' because the bug affects multiple users.