Refactor WindowFinder definition

Refactor WindowFinder definition

CL reworks the WindowFinder implementation as follows:

(Before):

- There was a WindowFinder base class, with empty ctor
and  dtor definitions, and one method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.

- There used to be a derived class WindowFinderMus, overriding
GetLocalProcessWindowAtPoint.

- TabDragController instantiated either WindowFinder or
WindowFinderMus depending whether the "Mus" code path is
being executed.

(After)

- The Mac platform does not support Mus. So only
 window_finder_mac.mm and window_finder.h are built.

- Other platforms (linux_desktop, chromeos, win) build
window_finder.cc, window_finder_mus.cc as well a platform
specific file; e.g. window_finder_chromeos.cc in case of
ChromeOS.

- CL also moves the logic that checks whether chrome is
running with the Mus path to within  GetLocalProcessWindowAtPointMus.

This CL is a preparation to CL [1], where chrome --mash
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
Committed: https://crrev.com/dad9ff3ca51c167a4473909bb68588b7ede0da52
Cr-Commit-Position: refs/heads/master@{#429010}

[tonikitoo, 2016-10-26 05:35:57]

tonikitoo@igalia.com changed reviewers:
+ rjkroege@chromium.org, sadrul@chromium.org

[tonikitoo, 2016-10-26 05:35:58]

PTAL

[tonikitoo, 2016-10-26 05:36:35]

tonikitoo@igalia.com changed reviewers:
+ sky@chromium.org

[fwang, 2016-10-26 07:42:57]

fwang@igalia.com changed reviewers:
+ fwang@igalia.com

[fwang, 2016-10-26 07:42:58]

l g t m

https://codereview.chromium.org/2449103004/diff/1/chrome/browser/ui/views/tab...
File chrome/browser/ui/views/tabs/window_finder.cc (right):

https://codereview.chromium.org/2449103004/diff/1/chrome/browser/ui/views/tab...
chrome/browser/ui/views/tabs/window_finder.cc:8: #include
"services/service_manager/runner/common/client_util.h"
It looks like these should be in a
#if defined(USE_AURA) && !defined(OS_MACOSX) too.

https://codereview.chromium.org/2449103004/diff/1/chrome/browser/ui/views/tab...
chrome/browser/ui/views/tabs/window_finder.cc:28: else
The else is no longer necessary since we leave the function at the return
statement.

[tonikitoo, 2016-10-26 13:41:46]

https://codereview.chromium.org/2449103004/diff/1/chrome/browser/ui/views/tab...
File chrome/browser/ui/views/tabs/window_finder.cc (right):

https://codereview.chromium.org/2449103004/diff/1/chrome/browser/ui/views/tab...
chrome/browser/ui/views/tabs/window_finder.cc:8: #include
"services/service_manager/runner/common/client_util.h"
On 2016/10/26 07:42:58, fwang wrote:
> It looks like these should be in a
> #if defined(USE_AURA) && !defined(OS_MACOSX) too.

Done.

https://codereview.chromium.org/2449103004/diff/1/chrome/browser/ui/views/tab...
chrome/browser/ui/views/tabs/window_finder.cc:28: else
On 2016/10/26 07:42:58, fwang wrote:
> The else is no longer necessary since we leave the function at the return
> statement.

Done.

[tonikitoo, 2016-10-26 13:45:36]

Description was changed from

==========
Refactor WindowFinder definition

Right now, there is a WindowFinder class, with empty ctor and
dtor definitions, and the method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.
There is also a derived class WindowFinderMus, whose instance
is used in case of the "mus" code path.

Right now, TabDragController instanciates either WindowFinder or
WindowFinderMus depending whether the "mus" code path is being executed.

CL moves the logic that checks whether chrome is running with
the mus path to with in WindowFinder class, and simplifying its
definition.

This CL is a preparation to CL [1], where chrome --mash capabilities
are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

to

==========
Refactor WindowFinder definition to be used in ozone

The existing WindowFinder class has empty ctor and dtor definitions, and the
method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.
There is also a derived class WindowFinderMus, which overrides the definition of
the later.

TabDragController instantiates either WindowFinder or
WindowFinderMus depending whether the "mus" code path is being executed.

CL moves the logic that checks whether chrome is running 
with the mus path to within WindowFinder class, and then
simplifies its definition.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

[tonikitoo, 2016-10-26 13:45:57]

Description was changed from

==========
Refactor WindowFinder definition to be used in ozone

The existing WindowFinder class has empty ctor and dtor definitions, and the
method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.
There is also a derived class WindowFinderMus, which overrides the definition of
the later.

TabDragController instantiates either WindowFinder or
WindowFinderMus depending whether the "mus" code path is being executed.

CL moves the logic that checks whether chrome is running 
with the mus path to within WindowFinder class, and then
simplifies its definition.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

to

==========
Refactor WindowFinder definition

The existing WindowFinder class has empty ctor and dtor definitions, and the
method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.
There is also a derived class WindowFinderMus, which overrides the definition of
the later.

TabDragController instantiates either WindowFinder or
WindowFinderMus depending whether the "mus" code path is being executed.

CL moves the logic that checks whether chrome is running 
with the mus path to within WindowFinder class, and then
simplifies its definition.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

[tonikitoo, 2016-10-26 13:48:15]

Description was changed from

==========
Refactor WindowFinder definition

The existing WindowFinder class has empty ctor and dtor definitions, and the
method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.
There is also a derived class WindowFinderMus, which overrides the definition of
the later.

TabDragController instantiates either WindowFinder or
WindowFinderMus depending whether the "mus" code path is being executed.

CL moves the logic that checks whether chrome is running 
with the mus path to within WindowFinder class, and then
simplifies its definition.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

to

==========
Refactor WindowFinder definition

The existing WindowFinder class has empty ctor and dtor
definitions, and the method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.
There is also a derived class WindowFinderMus, which 
overrides the definition of the later.

TabDragController instantiates either WindowFinder or
WindowFinderMus depending whether the "mus" code path is
being executed.

CL moves the logic that checks whether chrome is running 
with the mus path to within WindowFinder class, and then
simplifies its definition.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

[not to use - tonikitoo, 2016-10-26 13:49:10]

The CQ bit was checked by tonikitoo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 13:49:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[fwang, 2016-10-26 13:57:14]

informal l g t m

[commit-bot: I haz the power, 2016-10-26 14:11:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-26 14:11:12]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[not to use - tonikitoo, 2016-10-26 14:44:46]

The CQ bit was checked by tonikitoo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-26 14:45:04]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-26 15:34:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-26 15:34:02]

Dry run: This issue passed the CQ dry run.

[sky, 2016-10-26 17:42:01]

Can you clarify why this is better? What exactly are you trying to make clearer
or accomplish?

[rjkroege, 2016-10-26 18:34:04]

On 2016/10/26 17:42:01, sky wrote:
> Can you clarify why this is better? What exactly are you trying to make
clearer
> or accomplish?

I can explain the overall goal but I'm still a bit fuzzy on how tonikitoo@,
fwang@ et al. plan on getting there: to run "mustash" chrome on Linux desktop
and thereby benefit from the coexistence of wayland and x11 backends in ozone
that would permit such a chrome to operate on either window system in Linux.

I have a preference for how this should happen that I think would be more
beneficial to mustash team in the short term but I don't think that I've yet
stated it sufficiently persuasively to tonikitoo@ and fwang@. :-)

I'll leave the detailed explanation of the why of this CL to tonikitoo@

[sky, 2016-10-26 19:26:00]

Ok, thanks for the clarification.

As to this fix, I would rather have window_finder_x11 check for mus
and then call to window_finder_mus.

  -Scott

On Wed, Oct 26, 2016 at 11:34 AM,  <rjkroege@chromium.org> wrote:
> On 2016/10/26 17:42:01, sky wrote:
>> Can you clarify why this is better? What exactly are you trying to make
> clearer
>> or accomplish?
>
> I can explain the overall goal but I'm still a bit fuzzy on how tonikitoo@,
> fwang@ et al. plan on getting there: to run "mustash" chrome on Linux
> desktop
> and thereby benefit from the coexistence of wayland and x11 backends in
> ozone
> that would permit such a chrome to operate on either window system in Linux.
>
> I have a preference for how this should happen that I think would be more
> beneficial to mustash team in the short term but I don't think that I've yet
> stated it sufficiently persuasively to tonikitoo@ and fwang@. :-)
>
> I'll leave the detailed explanation of the why of this CL to tonikitoo@
>
>
>
> https://codereview.chromium.org/2449103004/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[tonikitoo, 2016-10-26 19:30:46]

On 2016/10/26 17:42:01, sky wrote:

Thanks for looking @sky / @rjkroege.

> Can you clarify why this is better? What exactly are you trying to make
clearer
> or accomplish?

(Before the CL)

- we had WindowFinder and WindowFindewMus classes. An instance either one or
another is created depending on whether we were running "mus path" or not.

- The flip logic (to create an instance of WindowFinder or WindowFinderMus) used
to live in chrome/browser/ui/views/tabs/tab_drag_controller.cc

- the solely non-empty method of these classes is
::GetLocalProcessWindowAtPoint, declared virtual in WindowFinder, overridden in
WindowFindewMus.

- platform specific implementations of ::GetLocalProcessWindowAtPoint live in
window_finder_{x11,chromeos,win,mac}.cc

(With the CL)

- Only one class exist: WindowFinder; i.e. WindowFinderMus is gone.

- it is transparent to the caller of ::GetLocalProcessWindowAtPoint whether we
are running the "mus path" or not. The flip logic happens within WindowFinder.

- If we are in the "mus path" GetLocalProcessWindowAtPointMus is called.
Otherwise, the proper (platform specific) GetLocalProcessWindowAtPointImpl is
called.

- CL also renames platform-specific implementations of
::GetLocalProcessWindowAtPoint to ::GetLocalProcessWindowAtPointImpl. The former
calls the later.

As an end result, adding an Ozone implementation ::GetLocalProcessWindowAtPoint
of would be simpler. 

PS: This CL started as an attempt address robert's review comment here:
https://codereview.chromium.org/2408803002/diff/140001/chrome/browser/ui/view...

[tonikitoo, 2016-10-26 19:35:59]

On 2016/10/26 19:26:00, sky wrote:
> Ok, thanks for the clarification.
> 
> As to this fix, I would rather have window_finder_x11 check for mus
> and then call to window_finder_mus.
> 

the original idea was to make it easier for an ozone implementation of this
method.

When USE_OZONE is true, it means USE_X11 must be false, and window_finder_x11.cc
would not even get built :(

[sky, 2016-10-26 22:01:28]

https://codereview.chromium.org/2449103004/diff/40001/chrome/browser/ui/views...
File chrome/browser/ui/views/tabs/window_finder.cc (right):

https://codereview.chromium.org/2449103004/diff/40001/chrome/browser/ui/views...
chrome/browser/ui/views/tabs/window_finder.cc:23: #if defined(USE_AURA) &&
!defined(OS_MACOSX)
I dislike the amount of ifdefs needed as a result of this. I would prefer this
exist in the places that know about mash. WindowFinderMus need not be a class.
What is WindowFinderMus::GetLocalProcessWindowAtPoint() can be moved to a
function that is called as appropriate.

[not to use - tonikitoo, 2016-10-27 15:24:15]

The CQ bit was checked by tonikitoo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-27 15:24:26]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[not to use - tonikitoo, 2016-10-27 16:13:27]

The CQ bit was checked by tonikitoo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-27 16:13:58]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-27 17:34:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-27 17:34:12]

Dry run: This issue passed the CQ dry run.

[tonikitoo, 2016-10-27 17:40:21]

On 2016/10/26 22:01:28, sky wrote:
>
https://codereview.chromium.org/2449103004/diff/40001/chrome/browser/ui/views...
> File chrome/browser/ui/views/tabs/window_finder.cc (right):
> 
>
https://codereview.chromium.org/2449103004/diff/40001/chrome/browser/ui/views...
> chrome/browser/ui/views/tabs/window_finder.cc:23: #if defined(USE_AURA) &&
> !defined(OS_MACOSX)

> I dislike the amount of ifdefs needed as a result of this.

@sky: The ifdef existed in chrome/browser/ui/views/tabs/tab_drag_controller.cc,
where we are moving the flip code from.

i.e. CL moves the service_connection check from
TabDragController::TabDragController to within
WindowFinder::GetLocalProcessWindowAtPoint, to make it transparent to the caller
whether mus/ is used or not.
The original service_connection check was ifdef, as well as the included
headers, hence the ifdef's here.

Indeed, checking for OS_MACOSX was not needed, since USE_AURA implies
!OS_MACOSX. I removed this check. 

> I would prefer this
> exist in the places that know about mash.

WindowFinder would be the place aware of mash in this case. Maybe you had
something else in mind?

> WindowFinderMus need not be a class.
> What is WindowFinderMus::GetLocalProcessWindowAtPoint() can be moved to a
> function that is called as appropriate.

This happens with in this CL.

[sky, 2016-10-27 19:35:29]

As I stated earlier, I prefer the platforms that are aura to have the
check, not window_finder.cc. There should be a lot mess ifdefs then.

  -Scott

On Thu, Oct 27, 2016 at 10:40 AM,  <tonikitoo@igalia.com> wrote:
> On 2016/10/26 22:01:28, sky wrote:
>>
>
https://codereview.chromium.org/2449103004/diff/40001/chrome/browser/ui/views...
>> File chrome/browser/ui/views/tabs/window_finder.cc (right):
>>
>>
>
https://codereview.chromium.org/2449103004/diff/40001/chrome/browser/ui/views...
>> chrome/browser/ui/views/tabs/window_finder.cc:23: #if defined(USE_AURA) &&
>> !defined(OS_MACOSX)
>
>> I dislike the amount of ifdefs needed as a result of this.
>
> @sky: The ifdef existed in
> chrome/browser/ui/views/tabs/tab_drag_controller.cc,
> where we are moving the flip code from.
>
> i.e. CL moves the service_connection check from
> TabDragController::TabDragController to within
> WindowFinder::GetLocalProcessWindowAtPoint, to make it transparent to the
> caller
> whether mus/ is used or not.
> The original service_connection check was ifdef, as well as the included
> headers, hence the ifdef's here.
>
> Indeed, checking for OS_MACOSX was not needed, since USE_AURA implies
> !OS_MACOSX. I removed this check.
>
>> I would prefer this
>> exist in the places that know about mash.
>
> WindowFinder would be the place aware of mash in this case. Maybe you had
> something else in mind?
>
>> WindowFinderMus need not be a class.
>> What is WindowFinderMus::GetLocalProcessWindowAtPoint() can be moved to a
>> function that is called as appropriate.
>
> This happens with in this CL.
>
>
>
>
> https://codereview.chromium.org/2449103004/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[not to use - tonikitoo, 2016-10-27 20:59:03]

The CQ bit was checked by tonikitoo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-27 21:00:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-27 21:06:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-27 21:06:04]

Dry run: Try jobs failed on following builders:
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[not to use - tonikitoo, 2016-10-27 21:37:20]

The CQ bit was checked by tonikitoo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-27 21:38:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-27 21:43:57]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-27 21:43:58]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)
  android_clang_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_clan...)
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[not to use - tonikitoo, 2016-10-28 13:24:47]

Description was changed from

==========
Refactor WindowFinder definition

The existing WindowFinder class has empty ctor and dtor
definitions, and the method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.
There is also a derived class WindowFinderMus, which 
overrides the definition of the later.

TabDragController instantiates either WindowFinder or
WindowFinderMus depending whether the "mus" code path is
being executed.

CL moves the logic that checks whether chrome is running 
with the mus path to within WindowFinder class, and then
simplifies its definition.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

to

==========
Refactor WindowFinder definition

CL reworks the WindowFinder classes implementation as follows:

(Before):

- Right now, there is a WindowFinder class, with empty ctor 
and  dtor definitions, and the method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.

- There is also a derived class WindowFinderMus, whose 
instance is used in case of the "mus" code path.

- TabDragController instanciates either WindowFinder or
WindowFinderMus depending whether the "Mus" code path is 
being executed.

(After)

- Mac platform does not support Mus. So window_finder_mac.mm
implements WindowFinder class independently.

- Other platforms (linux_desktop, chromeos, win) build 
window_finder.cc as well a platform specific implementation 
files, e.g. window_finder_chromeos.cc in case of ChromeOS.

- CL also moves the logic that checks whether chrome is 
running with the Mus path to within WindowFinder class.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

[not to use - tonikitoo, 2016-10-28 13:25:04]

The CQ bit was checked by tonikitoo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-28 13:25:17]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[tonikitoo, 2016-10-28 13:57:41]

On 2016/10/27 19:35:29, sky wrote:
> As I stated earlier, I prefer the platforms that are aura to have the
> check, not window_finder.cc. There should be a lot mess ifdefs then.

hi @sky. I have uploaded patchset9 eliminating ifdef's. also uploaded the commit
message, explaining the logic.

PTAL.

[commit-bot: I haz the power, 2016-10-28 14:18:32]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-28 14:18:33]

Dry run: This issue passed the CQ dry run.

[sky, 2016-10-28 16:54:48]

https://codereview.chromium.org/2449103004/diff/160001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder.h (right):

https://codereview.chromium.org/2449103004/diff/160001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder.h:22: class WindowFinder {
There is no point in making this a class. A single function suffices. Here is
what I would like to see: no class here. Only the single function:
GetLocalProcessWindowAtPoint().

In window_finder_mus.h there is a function GetLocalProcessWindowAtPointMus()
(again no class, just a function). Make this function have a boolean return
value and an additional param gfx::NativeWindow* value. For the platforms that
support mus, e.g. win, x11... GetLocalProcessWindowAtPoint looks like:

if (GetLocalProcessWindowAtPointMus(...))
  return window;
// existing logic.

Make sense?

[not to use - tonikitoo, 2016-10-28 19:25:05]

The CQ bit was checked by tonikitoo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-28 19:25:56]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[not to use - tonikitoo, 2016-10-28 19:32:15]

Description was changed from

==========
Refactor WindowFinder definition

CL reworks the WindowFinder classes implementation as follows:

(Before):

- Right now, there is a WindowFinder class, with empty ctor 
and  dtor definitions, and the method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.

- There is also a derived class WindowFinderMus, whose 
instance is used in case of the "mus" code path.

- TabDragController instanciates either WindowFinder or
WindowFinderMus depending whether the "Mus" code path is 
being executed.

(After)

- Mac platform does not support Mus. So window_finder_mac.mm
implements WindowFinder class independently.

- Other platforms (linux_desktop, chromeos, win) build 
window_finder.cc as well a platform specific implementation 
files, e.g. window_finder_chromeos.cc in case of ChromeOS.

- CL also moves the logic that checks whether chrome is 
running with the Mus path to within WindowFinder class.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

to

==========
Refactor WindowFinder definition

CL reworks the WindowFinder implementation as follows:

(Before):

- There was a WindowFinder base class, with empty ctor 
and  dtor definitions, and one method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.

- There used to be a derived class WindowFinderMus, overriding
GetLocalProcessWindowAtPoint.

- TabDragController instantiated either WindowFinder or
WindowFinderMus depending whether the "Mus" code path is 
being executed.

(After)

- No more classes, but free functions.

- The Mac platform does not support Mus. So only
 window_finder_mac.mm and window_finder.h are built.

- Other platforms (linux_desktop, chromeos, win) build 
window_finder.cc, window_finder_mus.cc as well a platform
specific file; e.g. window_finder_chromeos.cc in case of
ChromeOS.

- CL also moves the logic that checks whether chrome is 
running with the Mus path to within  GetLocalProcessWindowAtPointMus.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

[commit-bot: I haz the power, 2016-10-28 19:52:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-28 19:52:32]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[tonikitoo, 2016-10-28 20:05:48]

https://codereview.chromium.org/2449103004/diff/160001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder.h (right):

https://codereview.chromium.org/2449103004/diff/160001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder.h:22: class WindowFinder {
On 2016/10/28 16:54:48, sky wrote:
> There is no point in making this a class. A single function suffices. Here is
> what I would like to see: no class here. Only the single function:
> GetLocalProcessWindowAtPoint().
> 
> In window_finder_mus.h there is a function GetLocalProcessWindowAtPointMus()
> (again no class, just a function). Make this function have a boolean return
> value and an additional param gfx::NativeWindow* value. For the platforms that
> support mus, e.g. win, x11... GetLocalProcessWindowAtPoint looks like:
> 
> if (GetLocalProcessWindowAtPointMus(...))
>   return window;
> // existing logic.
> 
> Make sense?

Yes, it makes sense. patchset 10 implements the idea.

The biggest problem I see now is the unittest
chrome/browser/ui/views/tabs/tab_drag_controller_interactive_uitest.cc , where
WindowFinder is derived and GetLocalProcessWindowAtPoint overriden.

[sky, 2016-10-28 21:47:38]

On 2016/10/28 20:05:48, tonikitoo wrote:
>
https://codereview.chromium.org/2449103004/diff/160001/chrome/browser/ui/view...
> File chrome/browser/ui/views/tabs/window_finder.h (right):
> 
>
https://codereview.chromium.org/2449103004/diff/160001/chrome/browser/ui/view...
> chrome/browser/ui/views/tabs/window_finder.h:22: class WindowFinder {
> On 2016/10/28 16:54:48, sky wrote:
> > There is no point in making this a class. A single function suffices. Here
is
> > what I would like to see: no class here. Only the single function:
> > GetLocalProcessWindowAtPoint().
> > 
> > In window_finder_mus.h there is a function GetLocalProcessWindowAtPointMus()
> > (again no class, just a function). Make this function have a boolean return
> > value and an additional param gfx::NativeWindow* value. For the platforms
that
> > support mus, e.g. win, x11... GetLocalProcessWindowAtPoint looks like:
> > 
> > if (GetLocalProcessWindowAtPointMus(...))
> >   return window;
> > // existing logic.
> > 
> > Make sense?
> 
> Yes, it makes sense. patchset 10 implements the idea.
> 
> The biggest problem I see now is the unittest
> chrome/browser/ui/views/tabs/tab_drag_controller_interactive_uitest.cc , where
> WindowFinder is derived and GetLocalProcessWindowAtPoint overriden.

Bummer. That means we need to keep the class.
I want roughly what I outlined previously, but with the class. That is, the
implementations get:

if (GetLocalProcessWindowAtPointMus(...))
  return ...
// else local code

GetLocalProcessWindowAtPointMus is defined in window_finder_mus.h and is not in
a class.

[tonikitoo, 2016-10-28 21:52:19]

On 2016/10/28 21:47:38, sky wrote:
> On 2016/10/28 20:05:48, tonikitoo wrote:
> >
>
https://codereview.chromium.org/2449103004/diff/160001/chrome/browser/ui/view...
> > File chrome/browser/ui/views/tabs/window_finder.h (right):
> > 
> >
>
https://codereview.chromium.org/2449103004/diff/160001/chrome/browser/ui/view...
> > chrome/browser/ui/views/tabs/window_finder.h:22: class WindowFinder {
> > On 2016/10/28 16:54:48, sky wrote:
> > > There is no point in making this a class. A single function suffices. Here
> is
> > > what I would like to see: no class here. Only the single function:
> > > GetLocalProcessWindowAtPoint().
> > > 
> > > In window_finder_mus.h there is a function
GetLocalProcessWindowAtPointMus()
> > > (again no class, just a function). Make this function have a boolean
return
> > > value and an additional param gfx::NativeWindow* value. For the platforms
> that
> > > support mus, e.g. win, x11... GetLocalProcessWindowAtPoint looks like:
> > > 
> > > if (GetLocalProcessWindowAtPointMus(...))
> > >   return window;
> > > // existing logic.
> > > 
> > > Make sense?
> > 
> > Yes, it makes sense. patchset 10 implements the idea.
> > 
> > The biggest problem I see now is the unittest
> > chrome/browser/ui/views/tabs/tab_drag_controller_interactive_uitest.cc ,
where
> > WindowFinder is derived and GetLocalProcessWindowAtPoint overriden.
> 
> Bummer. That means we need to keep the class.
> I want roughly what I outlined previously, but with the class. That is, the
> implementations get:
> 
> if (GetLocalProcessWindowAtPointMus(...))
>   return ...
> // else local code
> 
> GetLocalProcessWindowAtPointMus is defined in window_finder_mus.h and is not
in
> a class.

Done in patchset11

[not to use - tonikitoo, 2016-10-28 23:48:02]

The CQ bit was checked by tonikitoo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-10-28 23:48:22]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[tonikitoo, 2016-10-28 23:49:02]

Description was changed from

==========
Refactor WindowFinder definition

CL reworks the WindowFinder implementation as follows:

(Before):

- There was a WindowFinder base class, with empty ctor 
and  dtor definitions, and one method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.

- There used to be a derived class WindowFinderMus, overriding
GetLocalProcessWindowAtPoint.

- TabDragController instantiated either WindowFinder or
WindowFinderMus depending whether the "Mus" code path is 
being executed.

(After)

- No more classes, but free functions.

- The Mac platform does not support Mus. So only
 window_finder_mac.mm and window_finder.h are built.

- Other platforms (linux_desktop, chromeos, win) build 
window_finder.cc, window_finder_mus.cc as well a platform
specific file; e.g. window_finder_chromeos.cc in case of
ChromeOS.

- CL also moves the logic that checks whether chrome is 
running with the Mus path to within  GetLocalProcessWindowAtPointMus.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

to

==========
Refactor WindowFinder definition

CL reworks the WindowFinder implementation as follows:

(Before):

- There was a WindowFinder base class, with empty ctor 
and  dtor definitions, and one method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.

- There used to be a derived class WindowFinderMus, overriding
GetLocalProcessWindowAtPoint.

- TabDragController instantiated either WindowFinder or
WindowFinderMus depending whether the "Mus" code path is 
being executed.

(After)

- The Mac platform does not support Mus. So only
 window_finder_mac.mm and window_finder.h are built.

- Other platforms (linux_desktop, chromeos, win) build 
window_finder.cc, window_finder_mus.cc as well a platform
specific file; e.g. window_finder_chromeos.cc in case of
ChromeOS.

- CL also moves the logic that checks whether chrome is 
running with the Mus path to within  GetLocalProcessWindowAtPointMus.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

[commit-bot: I haz the power, 2016-10-29 00:48:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-29 00:48:51]

Dry run: This issue passed the CQ dry run.

[fwang, 2016-10-31 11:46:06]

OK, it's looking good :-)

https://codereview.chromium.org/2449103004/diff/200001/chrome/browser/ui/BUIL...
File chrome/browser/ui/BUILD.gn (right):

https://codereview.chromium.org/2449103004/diff/200001/chrome/browser/ui/BUIL...
chrome/browser/ui/BUILD.gn:3041: # - Mus is not support on Mac, so skip
window_finder_mus.cc.
*supported*

[tonikitoo, 2016-10-31 14:20:29]

https://codereview.chromium.org/2449103004/diff/200001/chrome/browser/ui/BUIL...
File chrome/browser/ui/BUILD.gn (right):

https://codereview.chromium.org/2449103004/diff/200001/chrome/browser/ui/BUIL...
chrome/browser/ui/BUILD.gn:3041: # - Mus is not support on Mac, so skip
window_finder_mus.cc.
On 2016/10/31 11:46:06, fwang wrote:
> *supported*

Done locally. will reupload with further review remarks, if any.

[sky, 2016-10-31 15:34:35]

In case I wasn't clear, when I said I want the implementation to look like:

if (GetLocalProcessWindowAtPointMus(...))
  return ...
// else local code

I'm referring to the implementation in the platform specific files, *not* the
implementation in window_finder.cc. The reason for this is because not all
platforms need this logic. Yes, it means some duplicated code but it's minor and
the end code is clearer.

[tonikitoo, 2016-10-31 16:39:58]

On 2016/10/31 15:34:35, sky wrote:
> In case I wasn't clear, when I said I want the implementation to look like:
> 
> if (GetLocalProcessWindowAtPointMus(...))
>   return ...
> // else local code
> 
> I'm referring to the implementation in the platform specific files, *not* the
> implementation in window_finder.cc. The reason for this is because not all
> platforms need this logic. Yes, it means some duplicated code but it's minor
and
> the end code is clearer.

Done. Your suggestion was not as clear to me as now, thanks.

[sky, 2016-10-31 20:32:46]

Your diff makes it look like window_finder_mus.h is being deleted. Please make
sure that isn't the case.

https://codereview.chromium.org/2449103004/diff/220001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder_mus.h (right):

https://codereview.chromium.org/2449103004/diff/220001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_mus.h:10: bool
GetLocalProcessWindowAtPointMus(
Add description.

[sky, 2016-10-31 20:33:20]

https://codereview.chromium.org/2449103004/diff/220001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder_chromeos.cc (right):

https://codereview.chromium.org/2449103004/diff/220001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_chromeos.cc:17: gfx::NativeWindow
out;
out is descriptive, maybe mus_result? (same comment for other files)

[tonikitoo, 2016-10-31 21:09:02]

On 2016/10/31 20:32:46, sky wrote:
> Your diff makes it look like window_finder_mus.h is being deleted. Please make
> sure that isn't the case.

It is not being deleted.

[tonikitoo, 2016-10-31 21:09:14]

https://codereview.chromium.org/2449103004/diff/220001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder_chromeos.cc (right):

https://codereview.chromium.org/2449103004/diff/220001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_chromeos.cc:17: gfx::NativeWindow
out;
On 2016/10/31 20:33:20, sky wrote:
> out is descriptive, maybe mus_result? (same comment for other files)

Done.

https://codereview.chromium.org/2449103004/diff/220001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder_mus.h (right):

https://codereview.chromium.org/2449103004/diff/220001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_mus.h:10: bool
GetLocalProcessWindowAtPointMus(
On 2016/10/31 20:32:46, sky wrote:
> Add description.

Done.

[sky, 2016-10-31 22:43:46]

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/tab_drag_controller.cc (right):

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/tab_drag_controller.cc:225: window_finder_(new
WindowFinder),
Use MakeUnique (see threads on chromium-dev).

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder_mus.cc (right):

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_mus.cc:17: 
no newline, and for safety always set mus_result to nullptr.

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_mus.cc:43: return false;
Why are you returning false here? Shouldn't this return true as if you get here
you're running in mus?

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder_mus.h (right):

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_mus.h:10: // When running in remote
service "mode", method looks up for the
How about:
Used to locate the aura::Window under the specified point when in mus. If
running in mus true is returned and |mus_result| is set to the aura::Window
associated with the ui::Window under the specified point. It's possible for true
to be returned and mus_result to be set to null.

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder_win.cc (right):

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_win.cc:239: gfx::NativeWindow
mus_result;
= null on these.

[tonikitoo, 2016-10-31 23:39:37]

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/tab_drag_controller.cc (right):

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/tab_drag_controller.cc:225: window_finder_(new
WindowFinder),
On 2016/10/31 22:43:45, sky wrote:
> Use MakeUnique (see threads on chromium-dev).

Done.

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder_mus.cc (right):

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_mus.cc:17: 
On 2016/10/31 22:43:46, sky wrote:
> no newline, and for safety always set mus_result to nullptr.

Done.

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_mus.cc:43: return false;
On 2016/10/31 22:43:46, sky wrote:
> Why are you returning false here? Shouldn't this return true as if you get
here
> you're running in mus?

Done.

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder_mus.h (right):

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_mus.h:10: // When running in remote
service "mode", method looks up for the
On 2016/10/31 22:43:46, sky wrote:
> How about:
> Used to locate the aura::Window under the specified point when in mus. If
> running in mus true is returned and |mus_result| is set to the aura::Window
> associated with the ui::Window under the specified point. It's possible for
true
> to be returned and mus_result to be set to null.

Done.

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder_win.cc (right):

https://codereview.chromium.org/2449103004/diff/240001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_win.cc:239: gfx::NativeWindow
mus_result;
On 2016/10/31 22:43:46, sky wrote:
> = null on these.

Done.

[Tom (Use chromium acct), 2016-11-01 02:36:39]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-11-01 02:36:54]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-01 03:20:56]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-11-01 03:20:57]

Dry run: This issue passed the CQ dry run.

[sky, 2016-11-01 15:07:38]

https://codereview.chromium.org/2449103004/diff/260001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder_mus.cc (right):

https://codereview.chromium.org/2449103004/diff/260001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_mus.cc:17:
content::ServiceManagerConnection* service_manager_connection =
For safety set mus_result to null early on.

[not to use - tonikitoo, 2016-11-01 15:16:00]

The CQ bit was checked by tonikitoo@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-11-01 15:16:23]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[tonikitoo, 2016-11-01 15:16:39]

https://codereview.chromium.org/2449103004/diff/260001/chrome/browser/ui/view...
File chrome/browser/ui/views/tabs/window_finder_mus.cc (right):

https://codereview.chromium.org/2449103004/diff/260001/chrome/browser/ui/view...
chrome/browser/ui/views/tabs/window_finder_mus.cc:17:
content::ServiceManagerConnection* service_manager_connection =
On 2016/11/01 15:07:38, sky wrote:
> For safety set mus_result to null early on. 

Done.

[sky, 2016-11-01 15:26:30]

LGTM

[tonikitoo, 2016-11-01 15:47:18]

The CQ bit was unchecked by tonikitoo@igalia.com

[tonikitoo, 2016-11-01 15:47:30]

The CQ bit was checked by tonikitoo@igalia.com

[commit-bot: I haz the power, 2016-11-01 15:47:44]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-11-01 15:54:56]

Description was changed from

==========
Refactor WindowFinder definition

CL reworks the WindowFinder implementation as follows:

(Before):

- There was a WindowFinder base class, with empty ctor 
and  dtor definitions, and one method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.

- There used to be a derived class WindowFinderMus, overriding
GetLocalProcessWindowAtPoint.

- TabDragController instantiated either WindowFinder or
WindowFinderMus depending whether the "Mus" code path is 
being executed.

(After)

- The Mac platform does not support Mus. So only
 window_finder_mac.mm and window_finder.h are built.

- Other platforms (linux_desktop, chromeos, win) build 
window_finder.cc, window_finder_mus.cc as well a platform
specific file; e.g. window_finder_chromeos.cc in case of
ChromeOS.

- CL also moves the logic that checks whether chrome is 
running with the Mus path to within  GetLocalProcessWindowAtPointMus.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

to

==========
Refactor WindowFinder definition

CL reworks the WindowFinder implementation as follows:

(Before):

- There was a WindowFinder base class, with empty ctor 
and  dtor definitions, and one method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.

- There used to be a derived class WindowFinderMus, overriding
GetLocalProcessWindowAtPoint.

- TabDragController instantiated either WindowFinder or
WindowFinderMus depending whether the "Mus" code path is 
being executed.

(After)

- The Mac platform does not support Mus. So only
 window_finder_mac.mm and window_finder.h are built.

- Other platforms (linux_desktop, chromeos, win) build 
window_finder.cc, window_finder_mus.cc as well a platform
specific file; e.g. window_finder_chromeos.cc in case of
ChromeOS.

- CL also moves the logic that checks whether chrome is 
running with the Mus path to within  GetLocalProcessWindowAtPointMus.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

[commit-bot: I haz the power, 2016-11-01 15:54:57]

Committed patchset #15 (id:280001)

[commit-bot: I haz the power, 2016-11-01 16:07:38]

Description was changed from

==========
Refactor WindowFinder definition

CL reworks the WindowFinder implementation as follows:

(Before):

- There was a WindowFinder base class, with empty ctor 
and  dtor definitions, and one method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.

- There used to be a derived class WindowFinderMus, overriding
GetLocalProcessWindowAtPoint.

- TabDragController instantiated either WindowFinder or
WindowFinderMus depending whether the "Mus" code path is 
being executed.

(After)

- The Mac platform does not support Mus. So only
 window_finder_mac.mm and window_finder.h are built.

- Other platforms (linux_desktop, chromeos, win) build 
window_finder.cc, window_finder_mus.cc as well a platform
specific file; e.g. window_finder_chromeos.cc in case of
ChromeOS.

- CL also moves the logic that checks whether chrome is 
running with the Mus path to within  GetLocalProcessWindowAtPointMus.

This CL is a preparation to CL [1], where chrome --mash 
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089
==========

to

==========
Refactor WindowFinder definition

CL reworks the WindowFinder implementation as follows:

(Before):

- There was a WindowFinder base class, with empty ctor
and  dtor definitions, and one method GetLocalProcessWindowAtPoint,
with platform specific implementations living in
window_finder_{x11,mac,chromeos,win}.

- There used to be a derived class WindowFinderMus, overriding
GetLocalProcessWindowAtPoint.

- TabDragController instantiated either WindowFinder or
WindowFinderMus depending whether the "Mus" code path is
being executed.

(After)

- The Mac platform does not support Mus. So only
 window_finder_mac.mm and window_finder.h are built.

- Other platforms (linux_desktop, chromeos, win) build
window_finder.cc, window_finder_mus.cc as well a platform
specific file; e.g. window_finder_chromeos.cc in case of
ChromeOS.

- CL also moves the logic that checks whether chrome is
running with the Mus path to within  GetLocalProcessWindowAtPointMus.

This CL is a preparation to CL [1], where chrome --mash
capabilities are extended to run through Ozone.

[1] https://codereview.chromium.org/2408803002/

BUG=295089

Committed: https://crrev.com/dad9ff3ca51c167a4473909bb68588b7ede0da52
Cr-Commit-Position: refs/heads/master@{#429010}
==========

[commit-bot: I haz the power, 2016-11-01 16:07:40]

Patchset 15 (id:??) landed as
https://crrev.com/dad9ff3ca51c167a4473909bb68588b7ede0da52
Cr-Commit-Position: refs/heads/master@{#429010}