As suggested, I am reporting it in this forum.
Mac OS 10.15.3
Audacity 2.4.1 (same problem is present in 2.4.0 but not in 2.3.x).
-
Start with Audacity NOT running.
-
Select a number of .wav or .aup files in Finder (I used 4), right-click, “Open With”, “Audacity”.
-
Audacity opens, and the files open as expected.
-
Click in the waveform of one of the opened files.
-
Command+B to create a label.
The label is created. It has a white background to show it has the keyboard focus.
EXPECTED BEHAVIOUR: Type the label name. The name appears. That is: keyboard focus is within the label.
OBSERVED BEHAVIOUR: Type the label name. Nothing happens. That is: despite appearances, keyboard focus is not within the label. While the label is in this “focused but not focused” state, the left and right arrows move the play head, the space bar starts and stops playback, and the letter B jumps back and plays a small amount of audio.
WORKING ROUND THE PROBLEM:
Option 1. Backspace. Assuming that you did not select a range within the track before pressing Command+B, an error message comes up: “Disallowed: You can only do this when playing and recording are stopped. (Pausing is not sufficient.)” – or “No Audio Selected: Select the audio for Delete key to use, then try again”. Click on OK, and it becomes possible to type into the label.
Option 2. If a range was selected before pressing Command+B, backspacing won’t help because it will delete the selection. In that case, use (for example) Effects > Normalize, and when the command window appears, cancel it. I suspect that displaying and dismissing any pop-up window would restore correct focus behaviour.
Option 3. Clicking on a different program (such as Safari) and then returning to Audacity also corrects the situation and gives focus to the label that looks as if it has focus. (I discovered this while composing this message).
NOTES:
This problem is almost 100% reliable. Observing it carefully now, I think that the file that comes up topmost when all the files were opened in step 2 sometimes works correctly, but all the other files do not. So it may in fact be 100% reliable for all the files except that one.
Once the problem has been got round, by whatever means, subsequent insertion and editing of labels is 100% reliable.