View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0019572 | MMW 5 | Main Panel | public | 2022-11-17 23:58 | 2023-11-20 09:37 |
| Reporter | peke | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | 5.0.3 | ||||
| Target Version | 5.2 | ||||
| Summary | 0019572: Editing tracks and sorting causes lost focus in tracklist (was List (by Album) views: Inline editing of Sort column loses focus) | ||||
| Description | Inline editing of Sort column looses focus. Test note: List must have larger number of tracks listed for easy replicate eg. for test I used artist Hans Zimmer with >100 tracks and at least 10 Albums | ||||
| Steps To Reproduce | 1. Use artist listing -> List (by album) 2. Select sort by Album Accending 3. Inline edit Album -> Delete album info (Do not press enter to confirm) 4. Start inline edit of Title 5. Focus lost | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Could you please eleborate what do you mean by steps: 3. Inline edit Album -> Delete album info (Do not press enter to confirm) 4. Start inline edit of Title |
|
|
I meant that if you click title even same track MM looses both selection and focus and if sort is Album (my test case) you need to scroll all the way down to get to edited track. Video showing steps sent offline If you edit track album and click to correct Title (Two slow clicks) and this happen you will start inline edit of wrong track. |
|
|
OK, but the fact that the track repositions after album edit (once the list is sorted by album) is intended behaviour IMO and not the bug? @Rusty / @Petr should confirm, but I think this was intended. |
|
|
I do not mind reposition just that List should follow focus on repositioning, so that user is capable to continue correcting tags for same track eg. same behavior like when you change from ascending to descending. Shown in video. |
|
|
I'm really unclear on what bug you're trying to describe whether in the text or in your video, but here's a summary of what I'm observing: 1) There is a bug in which selection is lost as a result of inline edits triggering sorting, but it's common to almost all views (list/list(by album)/browser). The bug manifests depending on how the edit is made: . a) if the user makes the edit and presses ENTER --> item is sorted and selection is preserved (i.e. there's no bug) . b) if the user makes the edit and clicks on another track OR album --> item is sorted and selection is lost, as would be expected since the user clicked another track/album and focus should be on that other track (i.e. there's no bug) . c) if the user makes the edit and clicks on another field within the same track --> item is sorted and selection is lost even though it should be preserved! . d) if the user makes the edit and clicks on an empty space which should not change selection --> item is sorted and selection is lost even though it should be preserved! note: if the user makes an edit and uses TAB to advance to the next field, then MM doesn't trigger sort (this makes sense as otherwise the track could get resorted numerous times as each field is edited. 2) Variants of the above occur when the user selects a track and edits fields within another dialog e.g. a) Edit a track in the Properties dialog --> item is sorted and selection is lost! b) Edit a track in the Auto-tag dialog --> item is sorted and selection is lost! Summary: cases 1c), d) and 2 a), b) are bugs that appear to be regressions since most of these issues had previously been fixed and verified at 0015475. Peke, is this what you were trying to describe? |
|
|
@Rusty You completely right 1. c) and 2. a), b) are bugs/regressions it is easy missed when you have multi sort criteria and small number of tracks or edit non main sort. |
