Don't check if a browser window is active when getting an application list in CrOS

Don't check if a browser window is active when getting an application list in CrOS

When running an extension with the minimized state, this is not added
to the application list because it is not active. However, the application
menu of the launcher is created from the application list so we don't see
this minimized extension in the launcher even though it is shown up in the
overview mode. Therefore, we don't need to check if a browser window is
active to create an application list.

BUG=495878

[joone, 2015-06-03 02:20:40]

joone.hur@intel.com changed reviewers:
+ oshima@chromium.org

[joone, 2015-06-03 02:20:41]

Please take a look at this CL.

[oshima, 2015-06-03 17:04:36]

On 2015/06/03 02:20:41, joone wrote:
> Please take a look at this CL.
This may not be the right way to fix. I'm still looking.

[oshima, 2015-06-03 19:38:35]

On 2015/06/03 17:04:36, oshima wrote:
> On 2015/06/03 02:20:41, joone wrote:
> > Please take a look at this CL.
> This may not be the right way to fix. I'm still looking.

So the problem is that a window shown in minimized state never activated, so it
hasn't been added to BrowserList::last_active_browser_ yet.
This seems to work on Linux because on Linux, because it first shows (maps) the
window, then minimized it, and its gets activated
when mapped (not sure if this is intentional or a bug). 

We may want to add the browser to the last_active_ at the end when created.
I actually wonder what's the behavior on Windows. Can you test if
BrowserList::SetLastActive gets called
for a browser window that was shown with minimized state on Window/Mac?

[joone, 2015-06-04 23:03:56]

On 2015/06/03 19:38:35, oshima wrote:
> On 2015/06/03 17:04:36, oshima wrote:
> > On 2015/06/03 02:20:41, joone wrote:
> > > Please take a look at this CL.
> > This may not be the right way to fix. I'm still looking.
> 
> So the problem is that a window shown in minimized state never activated, so
it
> hasn't been added to BrowserList::last_active_browser_ yet.
> This seems to work on Linux because on Linux, because it first shows (maps)
the
> window, then minimized it, and its gets activated
> when mapped (not sure if this is intentional or a bug). 
> 
> We may want to add the browser to the last_active_ at the end when created.
> I actually wonder what's the behavior on Windows. Can you test if
> BrowserList::SetLastActive gets called
> for a browser window that was shown with minimized state on Window/Mac?

BrowserList::SetLastActive is called on Mac:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/...

[oshima, 2015-06-04 23:09:48]

On 2015/06/04 23:03:56, joone wrote:
> On 2015/06/03 19:38:35, oshima wrote:
> > On 2015/06/03 17:04:36, oshima wrote:
> > > On 2015/06/03 02:20:41, joone wrote:
> > > > Please take a look at this CL.
> > > This may not be the right way to fix. I'm still looking.
> > 
> > So the problem is that a window shown in minimized state never activated, so
> it
> > hasn't been added to BrowserList::last_active_browser_ yet.
> > This seems to work on Linux because on Linux, because it first shows (maps)
> the
> > window, then minimized it, and its gets activated
> > when mapped (not sure if this is intentional or a bug). 
> > 
> > We may want to add the browser to the last_active_ at the end when created.
> > I actually wonder what's the behavior on Windows. Can you test if
> > BrowserList::SetLastActive gets called
> > for a browser window that was shown with minimized state on Window/Mac?
> 
> BrowserList::SetLastActive is called on Mac:
>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/...

ok, so mac is explicitly calling it regardless of show state. (I wonder why code
search didn't show the code)
What about windows?

[joone, 2015-06-05 22:46:33]

On 2015/06/04 23:09:48, oshima wrote:
> On 2015/06/04 23:03:56, joone wrote:
> > On 2015/06/03 19:38:35, oshima wrote:
> > > On 2015/06/03 17:04:36, oshima wrote:
> > > > On 2015/06/03 02:20:41, joone wrote:
> > > > > Please take a look at this CL.
> > > > This may not be the right way to fix. I'm still looking.
> > > 
> > > So the problem is that a window shown in minimized state never activated,
so
> > it
> > > hasn't been added to BrowserList::last_active_browser_ yet.
> > > This seems to work on Linux because on Linux, because it first shows
(maps)
> > the
> > > window, then minimized it, and its gets activated
> > > when mapped (not sure if this is intentional or a bug). 
> > > 
> > > We may want to add the browser to the last_active_ at the end when
created.
> > > I actually wonder what's the behavior on Windows. Can you test if
> > > BrowserList::SetLastActive gets called
> > > for a browser window that was shown with minimized state on Window/Mac?
> > 
> > BrowserList::SetLastActive is called on Mac:
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/...
> 
> ok, so mac is explicitly calling it regardless of show state. (I wonder why
code
> search didn't show the code)
> What about windows?

It is also called before calling HWNDMessageHandler::ShowWindowWithState on
Windows:

	BrowserList::SetLastActive [0x03BA03AF+31]
(d:\chromium\src\chrome\browser\ui\browser_list.cc:200)
	BrowserFrame::OnNativeWidgetActivationChanged [0x03A5C80D+29]
(d:\chromium\src\chrome\browser\ui\views\frame\browser_frame.cc:187)
	views::DesktopNativeWidgetAura::HandleActivationChanged [0x0F9200D2+18]
(d:\chromium\src\ui\views\widget\desktop_aura\desktop_native_widget_aura.cc:368)
	views::DesktopWindowTreeHostWin::HandleActivationChanged [0x0F923ECE+46]
(d:\chromium\src\ui\views\widget\desktop_aura\desktop_window_tree_host_win.cc:705)
	views::HWNDMessageHandler::PostProcessActivateMessage [0x0F9044FB+59]
(d:\chromium\src\ui\views\win\hwnd_message_handler.cc:1044)
	views::HWNDMessageHandler::OnWndProc [0x0F9042EC+572]
(d:\chromium\src\ui\views\win\hwnd_message_handler.cc:942)
	gfx::WindowImpl::WndProc [0x06081F2D+173]
(d:\chromium\src\ui\gfx\win\window_impl.cc:315)
	base::win::WrappedWindowProc<&gfx::WindowImpl::WndProc> [0x06080DA2+82]
(d:\chromium\src\base\win\wrapped_window_proc.h:76)
	gapfnScSendMessage [0x75F762FA+818]

[oshima, 2015-06-05 23:10:47]

So is it activating the window even for minimized window? What about
ShowInactive? Is it still activating?

On Fri, Jun 5, 2015 at 3:46 PM, <joone.hur@intel.com> wrote:

> On 2015/06/04 23:09:48, oshima wrote:
>
>> On 2015/06/04 23:03:56, joone wrote:
>> > On 2015/06/03 19:38:35, oshima wrote:
>> > > On 2015/06/03 17:04:36, oshima wrote:
>> > > > On 2015/06/03 02:20:41, joone wrote:
>> > > > > Please take a look at this CL.
>> > > > This may not be the right way to fix. I'm still looking.
>> > >
>> > > So the problem is that a window shown in minimized state never
>> activated,
>>
> so
>
>> > it
>> > > hasn't been added to BrowserList::last_active_browser_ yet.
>> > > This seems to work on Linux because on Linux, because it first shows
>>
> (maps)
>
>> > the
>> > > window, then minimized it, and its gets activated
>> > > when mapped (not sure if this is intentional or a bug).
>> > >
>> > > We may want to add the browser to the last_active_ at the end when
>>
> created.
>
>> > > I actually wonder what's the behavior on Windows. Can you test if
>> > > BrowserList::SetLastActive gets called
>> > > for a browser window that was shown with minimized state on
>> Window/Mac?
>> >
>> > BrowserList::SetLastActive is called on Mac:
>> >
>>
>
>
>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/browser/ui/...
>
>  ok, so mac is explicitly calling it regardless of show state. (I wonder
>> why
>>
> code
>
>> search didn't show the code)
>> What about windows?
>>
>
> It is also called before calling HWNDMessageHandler::ShowWindowWithState on
> Windows:
>
>         BrowserList::SetLastActive [0x03BA03AF+31]
> (d:\chromium\src\chrome\browser\ui\browser_list.cc:200)
>         BrowserFrame::OnNativeWidgetActivationChanged [0x03A5C80D+29]
> (d:\chromium\src\chrome\browser\ui\views\frame\browser_frame.cc:187)
>         views::DesktopNativeWidgetAura::HandleActivationChanged
> [0x0F9200D2+18]
>
>
(d:\chromium\src\ui\views\widget\desktop_aura\desktop_native_widget_aura.cc:368)
>         views::DesktopWindowTreeHostWin::HandleActivationChanged
> [0x0F923ECE+46]
>
>
(d:\chromium\src\ui\views\widget\desktop_aura\desktop_window_tree_host_win.cc:705)
>         views::HWNDMessageHandler::PostProcessActivateMessage
> [0x0F9044FB+59]
> (d:\chromium\src\ui\views\win\hwnd_message_handler.cc:1044)
>         views::HWNDMessageHandler::OnWndProc [0x0F9042EC+572]
> (d:\chromium\src\ui\views\win\hwnd_message_handler.cc:942)
>         gfx::WindowImpl::WndProc [0x06081F2D+173]
> (d:\chromium\src\ui\gfx\win\window_impl.cc:315)
>         base::win::WrappedWindowProc<&gfx::WindowImpl::WndProc>
> [0x06080DA2+82]
> (d:\chromium\src\base\win\wrapped_window_proc.h:76)
>         gapfnScSendMessage [0x75F762FA+818]
>
>
>
>
> https://codereview.chromium.org/1155533006/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[joone, 2015-06-06 00:08:15]

On 2015/06/05 23:10:47, oshima wrote:
> So is it activating the window even for minimized window? What about
> ShowInactive? Is it still activating?

Yes, I got this call stack for minimized window.

base::debug::StackTrace::StackTrace
BrowserList::SetLastActive 
BrowserFrame::OnNativeWidgetActivationChanged 
views::DesktopNativeWidgetAura::HandleActivationChanged 
views::DesktopWindowTreeHostWin::HandleActivationChanged
views::HWNDMessageHandler::PostProcessActivateMessage
views::HWNDMessageHandler::OnWndProc
gfx::WindowImpl::WndProc
base::win::WrappedWindowProc<&gfx::WindowImpl::WndProc>

Which ShowInative?

[oshima, 2015-06-06 00:40:37]

On 2015/06/06 00:08:15, joone wrote:
> On 2015/06/05 23:10:47, oshima wrote:
> > So is it activating the window even for minimized window? What about
> > ShowInactive? Is it still activating?
> 
> Yes, I got this call stack for minimized window.
> 
> base::debug::StackTrace::StackTrace
> BrowserList::SetLastActive 
> BrowserFrame::OnNativeWidgetActivationChanged 
> views::DesktopNativeWidgetAura::HandleActivationChanged 
> views::DesktopWindowTreeHostWin::HandleActivationChanged
> views::HWNDMessageHandler::PostProcessActivateMessage
> views::HWNDMessageHandler::OnWndProc
> gfx::WindowImpl::WndProc
> base::win::WrappedWindowProc<&gfx::WindowImpl::WndProc>
> 
> Which ShowInative?

never mind. looks like we do activate window even when showing in minimized
state. 
This is probably because we're not using SW_SHOWNA, but changing this behavior
is
way beyond your original scope. I'll take my opinion back and would suggest just
show it first then
minimize it. I'll update the comment in the original CL.