[Mac] Restore focus to the tab contents when dismissing the find bar....

[Mac] Restore focus to the previously focused view when dismissing the find bar.
If a result was found, restore focus to the tab contents.  This allows for
keyboard navigation using the find bar.

BUG=http://crbug.com/12657
BUG=http://crbug.com/21374
TEST=See test case in bug 21374

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=26214

[rohitrao (ping after 24h), 2009-09-09 18:18:11]

This is only a half-solution, since I don't save the originally focused view,
but this is better than what we have now.  I'll have to figure out where the
save call needs to go and try to share code with RWHVCocoa.

[rohitrao (ping after 24h), 2009-09-09 19:53:43]

On 2009/09/09 18:18:11, rohitrao wrote:
> This is only a half-solution, since I don't save the originally focused view,
> but this is better than what we have now.  I'll have to figure out where the
> save call needs to go and try to share code with RWHVCocoa.

Got bored and starting implementing the save functionality too.  A patch is up,
but it's not yet ready for a look.  Hold off on this for now.

[rohitrao (ping after 24h), 2009-09-10 16:33:33]

Avi, how does this save/restore focus code look to you?  Does this look like
something we can use in TabContentsViewMac also?

[Avi (use Gerrit), 2009-09-14 21:55:27]

Overall, LG.

http://codereview.chromium.org/201061/diff/10/6005
File chrome/browser/cocoa/focus_tracker.mm (right):

http://codereview.chromium.org/201061/diff/10/6005#newcode5
Line 5: #import "chrome/browser/cocoa/focus_tracker.h"
Interesting approach, and it makes sense to use a special class if it's that
tricky to get right.

In terms of usability, it seems kinda like a stack object (snapshot on
construction, restore on destruction). Do we want to try to make it C++ey for
that?

[rohitrao (ping after 24h), 2009-09-14 22:21:59]

http://codereview.chromium.org/201061/diff/10/6005
File chrome/browser/cocoa/focus_tracker.mm (right):

http://codereview.chromium.org/201061/diff/10/6005#newcode5
Line 5: #import "chrome/browser/cocoa/focus_tracker.h"
On 2009/09/14 21:55:27, Avi wrote:
> Interesting approach, and it makes sense to use a special class if it's that
> tricky to get right.

The code is also non-trivial and used in at least two different places, so I'd
rather consolidate it.

> In terms of usability, it seems kinda like a stack object (snapshot on
> construction, restore on destruction). Do we want to try to make it C++ey for
> that?

I can play around with this some more.  The real trouble with
restore-on-destruct is that I need to know the current window before I can
restore (hence the restoreFocusInWindow: selector).  There are also some cases
where I explicitly don't want to restore focus, so we'll need a good way to
handle that as well.

[Avi (use Gerrit), 2009-09-15 13:53:45]

On 2009/09/14 22:21:59, rohitrao wrote:
> The code is also non-trivial and used in at least two different places, so I'd
> rather consolidate it.

Exactly.
 
> > In terms of usability, it seems kinda like a stack object (snapshot on
> > construction, restore on destruction). Do we want to try to make it C++ey
for
> > that?
> 
> I can play around with this some more.  The real trouble with
> restore-on-destruct is that I need to know the current window before I can
> restore (hence the restoreFocusInWindow: selector).  There are also some cases
> where I explicitly don't want to restore focus, so we'll need a good way to
> handle that as well.

Gotcha.

Looks good.