Bugzilla – Bug 510
undo can change which tracks are selected, and focus
Last modified: 2018-08-20 11:51:28 UTC
1. select one or more tracks, and a time range which doesn't cover all the audio. 2. perform some action on the selected audio, eg delete. 3. undo. This can change which tracks are selected and which track is the focus. Confusing for visually impaired users. Details: - if prior to some action, undo, one of the selected tracks is the focus, then after the undo that tracks remains selected, but any other selected tracks are deselected. - if prior to some action, undo, one of the selected tracks is not the focus, then after the undo, only one of the tracks remains selected, and that track becomes the focus.
(In reply to comment #0) Reproduced on Linux and Mac OS X also. Added Steps to Reproduce. AFAICT, the bug only triggers if you change which track is selected using ENTER before making the edit. Changing the selected track with the mouse prevents the bug occurring. Selecting part of a track using the mouse or even doing so using the keyboard prevents the bug occurring providing you apply the edit after making that selection. The bug seems to have existed ever since keyboard navigation of the track was introduced.
See also bug 614 "Undo undoes Mute / Solo changes" which shares a similar workaround (select in the track after changing Mute / Solo).
Created attachment 400 [details] "May" fix the issue I believe the attached patch will correct the issues you're seeing. But, you'll need to give it a try to make sure I was looking at it correctly.
(In reply to comment #3) > Created an attachment (id=400) [details] > "May" fix the issue > > I believe the attached patch will correct the issues you're seeing. But, > you'll need to give it a try to make sure I was looking at it correctly. thanks Leland. The focus can also move, which isn't documented in the bug. I'm not sure whether this is because I didn't notice it, or it's been introduced since the bug was filed. Your patch is an improvement, but things still aren't right. For example: 1. starting with no selected tracks and no selected time range. 2. select tracks 3. select time range, for example using shift+right arrow 4. delete or something. 5. undo. selection state of tracks is unchanged, but the first selected track becomes the focus. Another example: 1. starting with no selected tracks and no selected time range. 2. select time range, for example using shift+right arrow. 3. select tracks 4. delete or something. 5. undo. All tracks become unselected, and first track is the focus. David.
Created attachment 415 [details] Must more extensive review of saving state Try this one David. I reviewed all actions in Menus.cpp and have added state saving where it seemed to be missing. I had no idea it would be so many (22). And that was only reviewing Menus.cpp. I believe that will get them all since all keyboard actions are tied to a menu or command action and they all go through Menus.cpp. (I still have a few to review in TrackPanel.cpp though) Leland
(In reply to comment #5) > Created an attachment (id=415) [details] > Must more extensive review of saving state > > Try this one David. I reviewed all actions in Menus.cpp and have added state > saving where it seemed to be missing. I had no idea it would be so many (22). > And that was only reviewing Menus.cpp. I believe that will get them all since > all keyboard actions are tied to a menu or command action and they all go > through Menus.cpp. (I still have a few to review in TrackPanel.cpp though) tested the patch, and so far I can't get the selection to change by pressing undo. The focus still changes to the first selected track - maybe this is in the stuff in trackpanel which you still have to review. (The focus change is far less a problem than the selection change, as the screen reader reads the focussed track after the undo.) thanks, David.
Patch committed in r12721. But, bug should state open to address the focus problem.
(In reply to comment #7) > bug should state open to address the focus problem. Agreed. And there may be a question whether undo should legitimately move the focus after Track Drop-Down Menu > Move Track Up/Down.
(In reply to comment #8) And there may be a question whether undo should legitimately move the > focus after Track Drop-Down Menu > Move Track Up/Down. I'm not sure what you mean. I think the desired behaviour is: 1. track "fred" is the focus. 2. fred is moved up or down, and remains the focus. 3. undo, and fred remains the focus. David.
The patch (attachment#415 [details]) may also fix bug 614.
(In reply to comment #6) David wrote: > tested the patch, and so far I can't get the selection to change by pressing > undo. When I tried this fix in October and April, I still "occasionally" got the selection reverting after Undo to where it was before applying the effect, so I was a bit unsure on whether the selection reversion was fully fixed, but I can't find any problem today. I tried all classes of effect (built-in, plug-ins) and tried Generate, and also tried with clips in the track. > The focus still changes to the first selected track - maybe this is in the > stuff in trackpanel which you still have to review. > (The focus change is far less a problem than the selection change, as the > screen reader reads the focussed track after the undo.) I too "sometimes" got focus reverting as well as selection when I tested before, but I have not seen the focus reverting once in extensive testing today. Do you have steps to reproduce that? I can't make it happen with the current steps given in the "Steps To Reproduce" box. Meantime I demoted this to P4 as you suggest in bug 33. On reflection, probably I should have split the focus issue to a separate bug, as it meant the selection fix was never on DEVEL - FIX MADE which made it harder to track.
Testing on W10 with audacity-2.3.0-alpha-86-11da92d66846706d83c4cd44a0d05ff34b0f3d4d This no longer happens I get correct expected behaviors throughout Same when I test on macOS 10.13.6 with 30Jul18 alpha Un particular Step 6 does not happen as described - it behaves properly and similarly for step 8
(In reply to Peter Sampson from comment #12) > Testing on W10 with > audacity-2.3.0-alpha-86-11da92d66846706d83c4cd44a0d05ff34b0f3d4d > This no longer happens I get correct expected behaviors throughout > > Same when I test on macOS 10.13.6 with 30Jul18 alpha > > Un particular Step 6 does not happen as described - it behaves properly > > and similarly for step 8 The change of focus part of the bug has not been fixed: see comment 7. However, the steps to reproduce where not updated, and it may be cleaner if this bug is closed, and I open a separate bug at some stage if I still think it's a significant problem.
Thanks David. I'd prefer a new bug, rather than a reopen, if the issue is having a bad impact on VI users and merits being a live issue.
