Bugzilla – Bug 2107
Mac Accessibility: if a text box is the focus, pressing enter does not press the default button
Last modified: 2020-03-15 06:05:11 UTC
In any dialog, if a text box is the focus, then pressing Enter does not press the default button. This bug occurs regardless of the Full keyboard access setting. If Full keyboard access is set to all controls, then the user can tab to a control other than a text box, and then press enter. However, this work around is not very user friendly. This bug has some similarities with bug 1329.
(In reply to David Bailes from comment #0) > In any dialog, if a text box is the focus, then pressing Enter does not > press the default button. This bug occurs regardless of the Full keyboard > access setting. > > If Full keyboard access is set to all controls, then the user can tab to a > control other than a text box, and then press enter. However, this work > around is not very user friendly. > > This bug has some similarities with bug 1329. Correction to work around: I think that after recent commits they should be able to tab to a control other than a text box, regardless of the full keyboard access setting.
James, I see the change in message you made at commit cf069c591714e7f152f54d5a49bfe12b9eebbec9: "This recovery file was saved by Audacity 2.3.0 or before.\n" "You need to run that version of Audacity to recover the project." Which no longer mentions a file path. Well enough, but it occurs to me that there might sometimes be more than one recovery file. See the loop in RecoverAllProjects. Maybe Audacity crashed while you had two unsaved project windows open! I think the error will come up separately for each file and it could be unclear which is meant, in the loop in function RecoverAllProjects. Maybe the warning should be hoisted up out of the loop and changed to say "one or more" not "this". Though I admit we are multiplying the improbabilities of usage now.
Disregard previous comment, it was intended for a different issue
Proposed fix for bug 2107 at https://github.com/audacity/audacity/pull/361
(In reply to Paul L from comment #4) > Proposed fix for bug 2107 at https://github.com/audacity/audacity/pull/361 My understanding of the fix, is that your new code will get called for both char_hook and key_up events, and I'm not sure that's safe. What happens if a dialog is opened within a dialog - would pressing Enter close both? Can't test this, so my understanding may be wrong, but thought it would be safest to raise the issue.
The first point make sense, so I amended at commit d9c582a183cd5a9a3dea5788a7ef472cf71a1f74 The second point should not matter. Each dialog is a top level window. wxGetTopLevelParent ascends the chain of ancestry from the focus until the first top level window it encounters and then stops. As the documentation says: "Returns the first top level parent of the given window, or in other words, the frame or dialog containing it, or NULL." https://docs.wxwidgets.org/3.0/group__group__funcmacro__misc.html#ga3a5f33038df32c170c234a0161cfd702
(In reply to Paul L from comment #6) ... so what I did should be just equivalent to pressing the default button of the dialog that does contain the focus.
(In reply to Paul L from comment #6) > The first point make sense, so I amended at commit > d9c582a183cd5a9a3dea5788a7ef472cf71a1f74 > > The second point should not matter. Each dialog is a top level window. > wxGetTopLevelParent ascends the chain of ancestry from the focus until the > first top level window it encounters and then stops. As the documentation > says: > > "Returns the first top level parent of the given window, or in other words, > the frame or dialog containing it, or NULL." > > https://docs.wxwidgets.org/3.0/group__group__funcmacro__misc. > html#ga3a5f33038df32c170c234a0161cfd702 My worry was that for a single press of return, after the char_hook event the dialog would close, and if the focus returned to the previous dialog before the key_up event, then that event would close that dialog. Again, thoughts untested.
(In reply to Paul L from comment #4) > Proposed fix for bug 2107 at https://github.com/audacity/audacity/pull/361 Just an observation: On Windows, CommandManagerEventMonitor::FilterEvent() is not called when the focus is in a modal dialog, but I presume that it must be on macOS, otherwise the fix wouldn't work.
Marked must-test-all-os +ve in view of comment 9. A proposed fix must be tested on Linux too, not just windows and mac, as linux handles modal dialog messages differently to Windows.
DEVEL - FIX MADE https://github.com/audacity/audacity/commit/da66806bc0a1c5ef517a8403621a2e2dae401f0e IF this works on Mac, it is worth also testing Bug 1329.
MacOS 10.14.6, Commit: efc951 WORKS!!!! Thanks James! That's been a "fly in the ointment" for a long time.
Also works for Bug 1329.
Testing on W10 with audacity-2.3.3-alpha-323-80ef42433899446f6fc11701a961fb0a5f66290e On W10 this works properly a) the OK text button is higlighted by default - and works when you press Enter b) tabbing the the other 3 text buttons works - and take appropriate effect when you press Enter c) tabbing to the Help button works and pressing Enter takes you to the help
I confirm Cliff's test with 2.3.3 alpha jc008
The fix had a bad unintended consequence: see bug2267 I'm reopening this, for re-verification after a fix for 2267 is made.
bug 2267 is now fixed a https://github.com/audacity/audacity/commit/8b532546c905af1168a5d654dc71dda6a5188af5
(In reply to Paul L from comment #17) Testing on macOS 10,15.2 with Cliff's build of 29Dec10 On invoking amplify there is 1) a blue focus box around the "Manage" button 2) and the OK button is dark blue with focus 3) on pressing Tab, the blue box focus shifts to "Preview" 4) the OK button is dark blue with focus 5) Press Enter 6) observe the Preview is not effected - rather the Amply is effected on the selected audio Note that on W10 the initial focus on launching Amplify is on the "Amplification (dB):" level And on W10 tabbing to the Manage button or the Preview button and pressing Enter will invoke those functions and not apply the effect.
Testing on macOS Mojave, Audacity commit #06d4c0, I find that the initial focus cannot be seen. Tab will move to the Amplification text field. Tabbing again moves to the New Peak Amplitude text field. Enter will apply Amplify from either of these fields. The next tabbing goes somewhere invisible, but no blue line to identify where it is is visible. Note: Strangely, changing focus from Audacity to some other task then to Audacity back will then show the Amplification text field in focus.
Testing on macOS 10.15.3 with Audacity 2.4.0 f14a3dd This seems to work fine for me on Mac 1) Following the Steps to reproduce: at Step 4 the amplification is applied Note that it also works if at Step 2 you tab on to the second text box Observe the OK button is highlighted throuhgout 2) using default amplification level calculated for the audio a) select audio b) Effect > Amliify c) Observe: Audacity has calculated a gain to take the audio to 0dB d) Observe: the OK button is highlighted (focused?) e) Press Enter f) Observe: the requisite amplification is applied These tests suggest to me that this is working as intended now on Mac - and I think this bug can be closed. --------------------------------------------- The tabbing issues observed and commented on in this thread may or may not be a bug - but if they are a bug then that is a separate issue that would need to be logged. On Mac it certainly behaves differently on Windows. On Windows when Amplify is opened a) the focus is on the first text (numeric) box b) but there is also a Focus blue box around the OK button ( so steps 1 and 2 as tested above work just the same. c) repeated tabbing shifts the focus as follows i) focus shifts to the slider (which can be moved with left-arrow and right-arrow) - (focus removed from first text box but remains on the OK button as well) ii) next tab takes focus to second text (numeric) box iii) next tab takes focus to "Allow Clipping" (and focus also remains on OK button) iv) next tab shifts Focus to the Manage button - and removes focus now from the OK button v) next tab shifts focus to Preview button vi) next tab shifts focus to Cancel button vii) next tab shifts focus to "?" help button viii) next tab shifts focus to OK button ix) then we cycle back to the first text (numeric box) On Mac it is a lot different i) initial focus is on the OK button ii) first tab does nothing - focus remains on OK button iii) second use of tab gives focus yo the first text (numeric) box - the OK button remains focused iv) next tab switched focus from first text(numeric) box to second text(numeric) box (omits slider, unlike Windows) OK button still also retains focus v) next tab - only the OK button is focused ("Allow clipping" is skipped over, unlike Windows) vi) next tab cycles focus back to the first text(numeric) box - (omitting journeying to the Manage/Preview/Cancel/? buttons - unlike Windows) So we see that the tabbing behavior is markedly different on Mac to Windows - and I suspect that the Windows behavior is preferable as it provides keyboard access to the entire effect dialog inputs. But this is a different issue from that logged in this bug which expects the default "OK" button to be activated when pressing Enter (with focus on the first text(numeric) box - which indeed does now happen which is why I think this bug is fixed - and the tabbing is a different issue that we may not may not wish to log/fix. Does anybody disagree ?
I see what Peter sees on MacOS. If the keyboard shortcuts system setting is set to "All Controls" then the behavior is the same on MacOS. Since is appears that it is acceptable to require the user to switch to "All Controls" from the default setting of "Text boxes & Lists Only" for full access by tabbing to all fields in some functions I will mark this as fixed and close this bug.
