View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015475 | MMW 5 | Tracklist | public | 2019-02-19 00:28 | 2022-11-18 03:42 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0015475: Dynamic sorting issues | ||||
| Description | There are a few issues with how focus is handled when tracks in the tracklist are dynamically sorted: e.g. sort by Album Artist in Descending order. If a track's Album field is edited in-place (e.g. changed from aAlbum to zAlbum) , and the user presses ENTER --> 1) The re-sort repositioning of the list isn't immediate (it seems to happen after the tag is updated) --> 2) The position of the list fails to update correctly (see video) (focus correctly remains on the selected track) 3) If the user is using the keyboard to TAB through fields and modify them --> Focus is sometimes lost during the re-ordering/sorting (or worse, focus sometimes ends up on the wrong track)! It would probably make sense to _not_ resort tracks dynamically when TABbing between fields. See: https://www.screencast.com/t/TTo8bAzcGP 4) As with case 2), there are other cases where dynamic sorting causes the user to lose context--anytime the user selects a track and edits it outside of the tracklist. e.g. a) select a track and edit it in Properties b) select a track and edit it in Auto-tag --> in both cases, the track(s) get dynamically sorted and the user loses their place/context in the tracklist. Note: for issues 3/4 Free Commander is an example of a similar app that doesn't dynamically resort in such cases. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2265 | ||||
| related to | 0013437 | closed | petr | Browser view: position changes / scrolls by itself [on track edit] |
| related to | 0016915 | closed | petr | Issue with 2 instances of same song in a playlist |
| related to | 0016961 | closed | petr | Selected file problem on sort in Playlists |
| related to | 0016988 | resolved | petr | Tracklist moves and touch menus de-activate on track transition |
| related to | 0017299 | resolved | Ludek | Focused track gets out of view after resort (regression) |
| related to | 0017864 | closed | Ludek | Selection lost on sort |
| related to | 0019572 | assigned | petr | Editing tracks and sorting causes lost focus in tracklist (was List (by Album) views: Inline editing of Sort column loses focus) |
|
|
Items 1, 3 fixed |
|
|
Verified 1&3 in build 2223. Issues 2, 4 remain open. I've left this as 'urgent' as the issue is quite severe since it makes in-place editing quite a chore. |
|
|
Fixed |
|
|
Verified 2262 It looks like all is fixed. NOTE: I tested 1,3 for regressions also |
|
|
Tested 2263 and this isn't fully fixed: 2) Upon editing a field in-place: a) the position of the list fails to update b) focus on the selected track is lost (regression) 4) Upon editing a field in Properties, the item is re-sorted, BUT focus on the selected item is lost! Both of these issues are demonstrated here: https://www.screencast.com/t/LX1i2Pq7 |
|
|
Fixed |
|
|
Test note: 0013437 0014393 and 0015185 should be reverified at the same time (i.e. in 2264). |
|
|
Tested 2264 and: 2a,b) Verified c) If the user edits a track in-place and then clicks the track above or below --> the view shifts to the position of the edited track and focus doesn't shift to the track that was clicked! 4) This isn't fixed. i.e. after editing the Album for a single track in Properties --> focus is removed from the track (so if the users presses the UP/DOWN arrows they are unable to quickly navigate to the edited track. See: https://www.screencast.com/t/ivkeY2ekt00 Note: items at 0015475:0059387 should be tested once these issues are fully resolved. |
|
|
Item 2c fixed |
|
|
Fixed |
|
|
Verified 2c in 2265 @Petr What is fixed state of point 4? |
|
|
4a is fixed |
|
|
Reminder sent to: rusty Verified 2, 4a in 2267 Re verified for regressions 1, 3 in 2267 @Rusty please close after all related in 0015475:0059387 are retested. |
|
|
Another regression caused by fixing this is 0016988 |
|
|
Verified 2291 Unable replicate anymore |
