Bugzilla – Bug 1203
Mac OS X: Clicking in most upper dock toolbars or in the Timeline removes focus.
Last modified: 2018-08-20 11:46:06 UTC
Is this part and parcel of the loss of accessibility in Mac, or can some amelioration be incorporated for 2.1.2? I feel I must set P1 to discuss this, because the impact of this goes well beyond VI and motion impaired users. This will impact many "normal" workflows where the keyboard shortcut alternative to using the toolbar may not be familiar or convenient. COMMAND + F6 to restore focus is unlikely to be known by many sighted users. One tip: COMMAND + TAB twice to restore focus works and may be more discoverable or easier to use.
I'll look into it, but I'm not sure if it is a P1. If the person is using the mouse to click a toolbar control, then I'd wager that most of the folks don't even know what focus is and, if they do, probably don't care since they'd be using the mouse to interact with the track panel again...which would reestablish focus there.
(In reply to Leland Lucius from comment #1) I'm setting P1 to require us looking into what's needed. P1 may not be cast in stone this close to release, but earlier in release cycle I would not have not hesitated about P1. The problem really does not suit the user who reported it. I think it is quite natural to zoom or perform some other action with the mouse, but manipulate cursors and regions with the keyboard. If the keyboard action can be done in the left hand this can be more efficient/take less RSI than doing all with the mouse. If I used Mac as my main OS the loss of focus after clicking in the Timeline would inconvenience me a lot. Also consider that the keyboard track navigation may be more accurate or controllable than with the mouse.
I'm looking at it, but for the life of me figure out why it's doing it...or more correctly, why it hasn't been doing it all along. I've even been able make focus switch on Windows using one of your nightly builds, but it's not very repeatable. Hope to have a solution tonight.
I've a fix for it, but I have to figure out a way to test it on Windows somehow. I'm a bit concerned that it may affect keyboard navigation within the toolbars. I've attached a patch if y'all want to try it as I'm not sure I can get a Windows test environment set up.
Created attachment 632 [details] Possible fix
(In reply to Leland Lucius from comment #4) > I've a fix for it, but I have to figure out a way to test it on Windows > somehow. I'm a bit concerned that it may affect keyboard navigation within > the toolbars. > > I've attached a patch if y'all want to try it as I'm not sure I can get a > Windows test environment set up. I've briefly test this. Keyboard navigation within the toolbars seems fine. However, on a couple of occasions, ctrl+f6 stopped working. Unfortunately this doesn't seem to be reproducible, and I haven't managed to get it to go wrong again. The first time the focus was the tracks, and ctrl+f6 wouldn't move to the selection bar (didn't try ctrl+shift+f6 unfortunately). I had debug on the second time, and I could only move between the tracks and the selection bar, and couldn't get to the main toolbars. I was getting setfocus() errors in the debug output.
(In reply to David Bailes from comment #6) > (In reply to Leland Lucius from comment #4) > > I've a fix for it, but I have to figure out a way to test it on Windows > > somehow. I'm a bit concerned that it may affect keyboard navigation within > > the toolbars. > > > > I've attached a patch if y'all want to try it as I'm not sure I can get a > > Windows test environment set up. > > I've briefly test this. > Keyboard navigation within the toolbars seems fine. > However, on a couple of occasions, ctrl+f6 stopped working. Unfortunately > this doesn't seem to be reproducible, and I haven't managed to get it to go > wrong again. > The first time the focus was the tracks, and ctrl+f6 wouldn't move to the > selection bar (didn't try ctrl+shift+f6 unfortunately). > I had debug on the second time, and I could only move between the tracks and > the selection bar, and couldn't get to the main toolbars. I was getting > setfocus() errors in the debug output. Just to clarify, in the second case ctrl+f6 didn't stop working completely - I could move from the tracks to the selection bar, but not from the selection bar to the main toolbars.
Doesn't happen on W7-HP 64-bit audacity-win-r5f985a2-2.1.2-alpha-09-sep-15
(In reply to David Bailes from comment #6) > (In reply to Leland Lucius from comment #4) > > I've a fix for it, but I have to figure out a way to test it on Windows > > somehow. I'm a bit concerned that it may affect keyboard navigation within > > the toolbars. > > > > I've attached a patch if y'all want to try it as I'm not sure I can get a > > Windows test environment set up. > > I've briefly test this. > Keyboard navigation within the toolbars seems fine. > However, on a couple of occasions, ctrl+f6 stopped working. Unfortunately > this doesn't seem to be reproducible, and I haven't managed to get it to go > wrong again. > The first time the focus was the tracks, and ctrl+f6 wouldn't move to the > selection bar (didn't try ctrl+shift+f6 unfortunately). > I had debug on the second time, and I could only move between the tracks and > the selection bar, and couldn't get to the main toolbars. I was getting > setfocus() errors in the debug output. Just to add (and probably stating the obvious), I've no idea whether or not the patch caused these errors, although I haven't seen them before on my testing of 2.1.2.
Fix committed in pull request: https://github.com/audacity/audacity/pull/69
Pull request accepted. Status DEVEL-FIXMADE.
Thanks, Leland and David. I only tested on Yosemite so far. Certainly I don't lose focus now by clicking on Timeliine or upper tooldock toolbars. Keyboard navigation within Selection Toolbar and Spectral Selection Toolbar is OK with or without VoiceOver on. Keyboard navigation within the Upper Tooldock area does nothing with or without VoiceOver, but that is true pre-patch. With VoiceOver on, COMMAND + F6 and SHIFT + COMMAND + F6 cycle correctly. With VoiceOver off and Audacity restarted, COMMAND + F6 from the track gets trapped in Selection Toolbar. SHIFT + COMMAND + F6 once puts me back in the track, except that if I have navigated into Project Rate then even SHIFT + COMMAND + F6 does not get me out. If I can get back from Selection Toolbar to the track with SHIFT + COMMAND + F6, then another SHIFT + COMMAND + F6 does nothing, but I can still COMMAND + F6 into Selection Toolbar. The Project Rate issue is there pre-patch, but the other trappages are mew to this patch. I had not noticed before that wx3 on Mac also causes use of an undocked toolbar to remove focus from the track. This is normal on Windows and Linux but on Mac this is another regression on 2.1.1, perhaps a serious one for some users. There is no offsetting benefit because TAB inside undocked toolbars has never worked on Mac. Is there any real value in TAB inside undocked toolbars, versus the benefit of sighted users still being able to use keyboard shortcuts in the track after using an undocked toolbar?
Testing on El Capitan. The focus stays on the track when using the upper tool bars or timeline with the mouse. I also concur with what Gale reported in Comment 12 regarding the Selection Tool Bar except that with VoiceOver off or on Cmd+F6 immediately jumps to the Project rate and the focus is trapped there unless the mouse is clicked in another area. If focus is initially put into one of the three Selection time displays then Cmd+Shift+F6 takes the focus back to the track and from then on Cmd+F6/Cmd+Shift+F6 will cycle between the time displays and the track. With an undocked tool bar the focus is indeed lost from the track and cannot be restored with Cmd+F6 or Cmd+Shift+F6.
I'm RESOLVING this to get it out the way - remaining issues are not P1. Trappages cycling between track and tooldock areas on Mac are now at bug 1252 (P3). Inability to access upper tooldock/TAB not staying in its own tooldock is at bug 1247 (P3). Importance of an undocked toolbar removing focus from the track on Mac, which is normal on Windows and Linux, has not been decided yet.
