(In reply to Gale Andrews from comment #0)
> Regression on 2.1.2 on Windows and Mac. Track focus remaining after redock
> worked on Mac as recently as "10f77bc" of 29Jun16, but broke before that on
> Windows.   
> 
> It did not work properly in 2.1.2 on Linux Ubuntu 14.04 - although track
> focus border remained, SPACE did not play the track after dragging the
> toolbar.

Testing on Windows 10.
This issue is slightly more general.
Whatever control in the Audacity windows is the initial focus, it you click on either a toolbar grabber or resizer, then it becomes the focus, and the location of the new focus is not visually indicated.

(In reply to David Bailes from comment #1)
> (In reply to Gale Andrews from comment #0)
> > Regression on 2.1.2 on Windows and Mac. Track focus remaining after redock
> > worked on Mac as recently as "10f77bc" of 29Jun16, but broke before that on
> > Windows.   
> > 
> > It did not work properly in 2.1.2 on Linux Ubuntu 14.04 - although track
> > focus border remained, SPACE did not play the track after dragging the
> > toolbar.
> 
> Testing on Windows 10.
> This issue is slightly more general.
> Whatever control in the Audacity windows is the initial focus, it you click
> on either a toolbar grabber or resizer, then it becomes the focus, and the
> location of the new focus is not visually indicated.

Forgot to add that it was almost certainly introduced in commit 89e33da so that dragging and resizing can be cancelled by ESC.

ESC key cancelling drag is a very good thing in my opinion.  All drag actions should be cancellable.  Audacity is not there yet but in 2.1.3 I added ESC key handling to the dragging of toolbars, and the resizing of them (meter and device bars).

I don't want that development negated.  Some way to accomodate the demands of this bug too can be found.

Why does this bug merit P2?

I fixed another problem with toolbars here, which incidentally fixes part of this problem on Mac, though I do no understand why.

https://github.com/audacity/audacity/commit/db2ee75c0a21437c472d6abb6501aea08229d48c

Focus is now restored to tracks after a toobar docks or you hit ESC.  Focus dos not go to tracks if you release the toolbar in undocked position.

Before re-reading Paul's comment 4, I decided this didn't look like a potential release blocker (P2).  It is marked as an accessibility issue, but I don't get that, given mouse movement is needed to trigger it. So am lobbying to have the rating reduced - or the severity rating better explained.

(In reply to James Crook from comment #5)
Keyboard focus is an accessibility issue, so it is right that this should be mentioned in bug 33, even though there could be a case for a second release duplicating part of the bug 33 note. I have decided not to duplicate, but the bug 33 release note now takes on point David's point from comment 1 as follows: 

"After mouse down to drag a docked toolbar to a new docked or undocked position, the track focus is removed and the selected control loses its focus border even though that toolbar still has focus. When dragging or resizing an already undocked toolbar, the focused control similarly loses it focus border." 

I think David's point is important for accessibility because you should always be able to move through modeless windows, undocked Toolbars and the main project window using ALT + F6 or ALT + SHIFT + F6 and see a positive indication that the toolbar has focus. Once you have moved or resized the undocked toolbar, that indication is now lost and you must use TAB (when the toolbar has undeclared focus) to restore that indication. 

Bug title now takes into account David's point.

I think the compelling reason why it's P2 (or P2.5 and I round upwards) is when toolbars are docked and the user misaims and touches the grab bar of a toolbar instead of that toolbar's control. Selection Tool is arguably the most important tool in Tools Toolbar and is next to the grab handle. Pause (or Skip to Start if user changes the Transport Toolbar configuration) are important buttons next to a grab handle. If the user misaims, this bug will be really annoying as soon as we have for example some user who presses Pause then wants to keyboard interact with the track (such as draw a selection) many times a day. 

Please let's recognise the importance of repetitive workflows to Audacity and make them easier, not harder. Please let's recognise such workflows may mix mouse and keyboard actions, for whatever reason the user deems.            

I see another problem now that may not be on Bugzilla. In 2.1.2 on Windows, if you just left-click and release the grab handle without dragging, the toolbar redocks itself. But now Windows has the same issue as Mac and Linux -  left-click and release without drag on a grab handle floats the toolbar without redocking it. It still looks docked, but isn't. Was this too caused by letting ESC cancel toolbar drag? I don't think we should assume ESC cancelling drag of a toolbar is discoverable by everybody without RTDM. Release without drag is highly discoverable.

Title now "Undocking Toolbars removes track focus, and drag or resize of undocked toolbars removes the control's focus border". 

Steps to reproduce updated to include David's concern.

(In reply to Gale Andrews from comment #6)
> (In reply to James Crook from comment #5)
> Keyboard focus is an accessibility issue, so it is right that this should be
> mentioned in bug 33, even though there could be a case for a second release
> duplicating part of the bug 33 note.

Just to add that many visually impaired users use screen magnifiers with or without some screen reading functionality, and they use both keyboard and mouse. Screen magnifiers have there own clear indication of focus, which will almost certainly be incorrect due to this bug.

I consider the correct indication of focus is more important than the ability to escape the drag, and so if this bug can't be fixed before 2.1.3 whilst keeping the escape from drag, then I think that escape of the drag should be reverted.

As of this commit:

https://github.com/audacity/audacity/commit/2f178db70099b7237e84c014f2c885ee84768570

You will find that a simple click on the grabber of a toolbar will have no effect on focus.

I think this improvement answers the major complaint of comment 2 and maybe it justifies reduced priority.

But I am giving up for now on figuring out how to preserve the control focus in all cases of dragging.  It gets confusing and very different across platforms.

You might not expect focus to remain unchanged when you drag toolbars, but now you are protected from making a rearrangement unintnentionally with a click on the grabber.

I may have overinterpreted the title.  I think I have got drag and resize preserving the focused control, if that control is in the same bar, which satisfies part of the complaint.

If you mean, preserve control focus, even when in some other bar than the one moved -- no, I didn't get that working, and I have stopped trying to accomplish that.

Undocking toolbars still removes track focus.  But, as I said, that is now harder to do inadvertently with just a click in the grabber.

(In reply to Paul L from comment #9)
> As of this commit:
> 
> https://github.com/audacity/audacity/commit/
> 2f178db70099b7237e84c014f2c885ee84768570
> 
> You will find that a simple click on the grabber of a toolbar will have no
> effect on focus.

This seems to work, and is a definite improvement but is very buggy.
Start clicking on a few grabbers, and doing a few resizes, and it's not long before one or more toolbars disappear, along with other strange effects like toolbars being only partially visible.

> 
> I think this improvement answers the major complaint of comment 2 and maybe
> it justifies reduced priority.
> 
> But I am giving up for now on figuring out how to preserve the control focus
> in all cases of dragging.  It gets confusing and very different across
> platforms.
> 
> You might not expect focus to remain unchanged when you drag toolbars, but
> now you are protected from making a rearrangement unintnentionally with a
> click on the grabber.

My recent work introced some other problems when you click on a grabber without dragging, but those are fixed at:

https://github.com/audacity/audacity/commit/2d56c8ec3286aa0a4a22e5be9148a2a1e01b8e17


I will mark this fix made for QA to judge.  As I explained above, I think I fixed the spirit of the problem if not to the letter as stated.

(In reply to Paul L from comment #12)
Testing on macOS Sierra 10.12.5 00f8658 27Jul17

With a single audio track that has focus (or with multiple tacks with one with focus) clicking on the drag handle of any of the toolbars still removes focus (unnecessarily) from the selectected track.

So the first part of this bug report is not fixed (for Mac - can't test on Windows yet as no nightly build since the "fix")

As for the second part of the Bug report I don't see any focus toolbar round undocked toolbars items :-//

(In reply to Peter Sampson from comment #13)

I thought item #2 refers to the stippled square drawn about the button icon when you TAB to it, or blue borders around choice items, and so on.

I have tried to make it that when you have such in the toolbar that is dragged or resized, then you don't lose them.  That was my understanding of the other part of the complaint.

I found it too hard to keep the control focus in one toolbar when abother toolbar is dragged or resized.  I won't do it.

(In reply to Paul L from comment #12)
Testing on W10 audacity-win-aee0c4c-2.2.0-alpha-04-aug-17

On Windows the bug referred to in the title of this bug thread appears to be fixed.  

Undocking (or redocking) a Toolbar only now temporarily removes focus from the focused track.  The focus is restored once the repositioning is completed.   Similarly just clicking on a Toolbar's drag bar and then releasing the left mouse button without moving the Toolbar only temporarily removes focus, restoring it once the left mosuse button is released.

Observation:  I'm not at all sure why we (albeit temporarily) interfere with the focus on a track when working with a Toolbar like this - I see no reason or logic for this.  We don't, for instance, temporaily remove track focus when we press say a button in the Transport Toolbar -or when we move the sliders.

BUT I do note that if you double-click on the thumb-controls in the various sliders (including the sliders in the TCP of the focused track itself) to invoke the dropdown precision setting - the we do temporarily remove the track focus.  It is restored ok though.

Re-testing on macOS Sierra 10.12.6 3302455 05Aug17

The bug in the title of this thread is still not fixed on Mac.

Focus is not restored to a focused track when moving a toolbar or clicking on a toolbar's drag handle and releasing the left-mouse button.

Reopeneing this as it is still nit fixed on Mac

*** STEPS UPDATED ***

Testing on macOS 10.13.16 with Mac 2.3.0 alpha of 30July

Most of this appears to work with a residual issue that I shall log as s separate new bug.

In all of these cases the focus is temporarily removed from the track while the action is completed - but restores as soon as the action is completed
1) with focus on the track
2) clicking on any tool in either tooldock
3) resizing any tool in either tooldock
4) moving a tool within the upper or lower
5) moving a tool from one tooldock to the other
6) changing settings on any tool


But we do have this residual issue - with focus on the track, if a tool is dragged out of a tooldock to float it then focus on the track is (visibly) removed.
But if you then drag the tool back into either Tooldock the focus is restored,
This only happens on Mac .

There is a related issue on Mac that also happen on Windows whereby changing the setting in an undocked toolbar will remove the track's focus - I will be logging that as a new multi-platform bug

See Bug 1920 
Mac: undocking any tool removes track focus

and its close relative Bug 1921 
With focus on a track, changing settings in a floated toolbar causes the track to lose focus