ABANDONED: Focus the content when the wrench menu disappears.

Focus the content when the wrench menu disappears.

BUG=114536
TEST=none

[sadrul, 2012-02-23 14:51:23]

http://codereview.chromium.org/9456013/diff/3/chrome/browser/ui/views/wrench_...
File chrome/browser/ui/views/wrench_menu.cc (right):

http://codereview.chromium.org/9456013/diff/3/chrome/browser/ui/views/wrench_...
chrome/browser/ui/views/wrench_menu.cc:620: }
An alternate option is to expose GetTabContentsContainerView for non-testing
purpose (i.e. move from BrowserWindowTesting into BrowserWindow).

[Ben Goodger (Google), 2012-02-23 16:55:05]

I think there's a deeper problem than this. If you follow my STR on Windows
Chrome, it works, without your code.

So it sounds more like we're not restoring focus properly in aura/ash.

[sadrul, 2012-02-23 17:00:22]

On 2012/02/23 16:55:05, Ben Goodger (Google) wrote:
> I think there's a deeper problem than this. If you follow my STR on Windows
> Chrome, it works, without your code.
> 
> So it sounds more like we're not restoring focus properly in aura/ash.

Ah, interesting. There is a good chance this happens because of the call to
'RepostEvent' in MenuController::SetSelectionOnPointerDown. It makes sure the
event gets sent again so that the window where the click happened receives the
event. It is done only for non-aura windows.

In a linux build, clicking outside the menu simply cancels the menu; the window
the click happened on does not receive the click. Do we want to preserve this
behaviour for chromeos, or do we want to do what non-aura windows does, and
repost the event?

[Ben Goodger (Google), 2012-02-23 17:05:17]

When in doubt, match Windows.

-Ben

On Thu, Feb 23, 2012 at 9:00 AM, <sadrul@chromium.org> wrote:

> On 2012/02/23 16:55:05, Ben Goodger (Google) wrote:
>
>> I think there's a deeper problem than this. If you follow my STR on
>> Windows
>> Chrome, it works, without your code.
>>
>
>  So it sounds more like we're not restoring focus properly in aura/ash.
>>
>
> Ah, interesting. There is a good chance this happens because of the call to
> 'RepostEvent' in MenuController::**SetSelectionOnPointerDown. It makes
> sure the
> event gets sent again so that the window where the click happened receives
> the
> event. It is done only for non-aura windows.
>
> In a linux build, clicking outside the menu simply cancels the menu; the
> window
> the click happened on does not receive the click. Do we want to preserve
> this
> behaviour for chromeos, or do we want to do what non-aura windows does, and
> repost the event?
>
>
http://codereview.chromium.**org/9456013/<http://codereview.chromium.org/9456...
>