Add hovering feature to AshDevToolsDOMAgent

Add hovering feature to AshDevToolsDOMAgent

Hovering over any element in the frontend inspector will now highlight
the corresponding Ash window/widget/view. The highlight and border
color is whatever DevTools provides us in the highlightConfig. Currently,
this is a slightly transparent light blue overlay with a dark yellow
border.

How this is done:
- Create a widget in the primary root window under the OverlayContainer.
- Whenever a node is highlighted, call AshDevToolsDOMAgent::HighlightNode
on the main thread, which then determines where the object is (i.e: bounds)
and what display it is on.
- The parent |window| for the the |widget| that we created will update its
bounds and the |root_view| of the widget has its border/background color
updated to those provided in the highlightConfig.
- When no node is being hovered over, hideHighlight is called by the frontend
and we simply hide the widget.
- We also do not want to show the |widget| in the DOM tree, so if we ever
encounter its parent |window|, it will be ignored.

BUG=648701
Committed: https://crrev.com/ae977ac4847526a5674b7898617369e6d272cde7
Cr-Commit-Position: refs/heads/master@{#437069}

[Sarmad Hashmi, 2016-12-01 20:12:03]

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

[commit-bot: I haz the power, 2016-12-01 20:12:35]

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-12-01 20:51:09]

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

[commit-bot: I haz the power, 2016-12-01 20:51:09]

Dry run: This issue passed the CQ dry run.

[Sarmad Hashmi, 2016-12-03 01:50:46]

mhashmi@chromium.org changed reviewers:
+ sadrul@chromium.org

[Sarmad Hashmi, 2016-12-03 01:50:46]

PTAL sadrul@!

[Sarmad Hashmi, 2016-12-06 00:15:49]

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

[commit-bot: I haz the power, 2016-12-06 00:16:32]

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-12-06 00:51:34]

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

[commit-bot: I haz the power, 2016-12-06 00:51:35]

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

[sadrul, 2016-12-06 20:48:59]

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
File ash/common/devtools/ash_devtools_dom_agent.cc (right):

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
ash/common/devtools/ash_devtools_dom_agent.cc:94: rgba->getB());
Should we sanity check these values?

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
ash/common/devtools/ash_devtools_dom_agent.cc:125:
main_thread_task_runner_->PostTask(
Why do you need to PostTask()?

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
ash/common/devtools/ash_devtools_dom_agent.cc:475: view = view->parent();
Why is this needed?

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
ash/common/devtools/ash_devtools_dom_agent.cc:512:
window_and_bounds.first->GetDisplayNearestWindow());
Can you just SetBounds() on |widget_for_highlighting_| instead?

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
File ash/common/devtools/ash_devtools_dom_agent.h (right):

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
ash/common/devtools/ash_devtools_dom_agent.h:38: explicit AshDevToolsDOMAgent(
You don't need explicit anymore.

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
ash/common/devtools/ash_devtools_dom_agent.h:124: void
UpdateHighlight(std::pair<WmWindow*, gfx::Rect>,
const WindowAndBoundsPair&

https://codereview.chromium.org/2542243002/diff/60001/ash/common/wm_shell.cc
File ash/common/wm_shell.cc (right):

https://codereview.chromium.org/2542243002/diff/60001/ash/common/wm_shell.cc#...
ash/common/wm_shell.cc:97: this, base::MessageLoop::current()->task_runner());
Use base::ThreadTaskRunnerHandle::Get() instead. But maybe we don't need this?
See comment in dom-agent.cc

[Sarmad Hashmi, 2016-12-06 22:16:53]

Description was changed from

==========
Add hovering feature to AshDevToolsDOMAgent

Hovering over any element in the frontend inspector will now highlight
the corresponding Ash window/widget/view. The highlight and border
color is whatever DevTools provides us in the highlightConfig. Currently,
this is a slightly transparent light blue overlay with a dark yellow
border.

How this is done:
- Create a widget in the primary root window under the OverlayContainer.
- Whenever a node is highlighted, call AshDevToolsDOMAgent::HighlightNode
on the main thread, which then determines where the object is (i.e: bounds)
and what display it is on.
- The parent |window| for the the |widget| that we created will update its
bounds and the |root_view| of the widget has its border/background color
updated to those provided in the highlightConfig.
- When no node is being hovered over, hideHighlight is called by the frontend
and we simply hide the widget.
- We also do not want to show the |widget| in the DOM tree, so if we ever
encounter its parent |window|, it will be ignored.

BUG=648701
==========

to

==========
Add hovering feature to AshDevToolsDOMAgent

Hovering over any element in the frontend inspector will now highlight
the corresponding Ash window/widget/view. The highlight and border
color is whatever DevTools provides us in the highlightConfig. Currently,
this is a slightly transparent light blue overlay with a dark yellow
border.

How this is done:
- Create a widget in the primary root window under the OverlayContainer.
- Whenever a node is highlighted, call AshDevToolsDOMAgent::HighlightNode
on the main thread, which then determines where the object is (i.e: bounds)
and what display it is on.
- The parent |window| for the the |widget| that we created will update its
bounds and the |root_view| of the widget has its border/background color
updated to those provided in the highlightConfig.
- When no node is being hovered over, hideHighlight is called by the frontend
and we simply hide the widget.
- We also do not want to show the |widget| in the DOM tree, so if we ever
encounter its parent |window|, it will be ignored.

Minor fix:
- Add UI_DEVTOOLS_EXPORT to static methods in UiDevToolsServer

BUG=648701,669352
==========

[Sarmad Hashmi, 2016-12-06 22:54:01]

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

[commit-bot: I haz the power, 2016-12-06 22:54:34]

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

[Sarmad Hashmi, 2016-12-06 22:54:34]

Also fixed the small bug here https://crbug.com/669352

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
File ash/common/devtools/ash_devtools_dom_agent.cc (right):

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
ash/common/devtools/ash_devtools_dom_agent.cc:94: rgba->getB());
On 2016/12/06 20:48:58, sadrul (OOO) wrote:
> Should we sanity check these values?

Done.

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
ash/common/devtools/ash_devtools_dom_agent.cc:125:
main_thread_task_runner_->PostTask(
On 2016/12/06 20:48:59, sadrul (OOO) wrote:
> Why do you need to PostTask()?

Removed, as discussed.

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
ash/common/devtools/ash_devtools_dom_agent.cc:475: view = view->parent();
On 2016/12/06 20:48:58, sadrul (OOO) wrote:
> Why is this needed?

Sorry, thought an earlier bug I was encountering was solved by this. Seems like
it works without. Removed.

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
ash/common/devtools/ash_devtools_dom_agent.cc:512:
window_and_bounds.first->GetDisplayNearestWindow());
On 2016/12/06 20:48:59, sadrul (OOO) wrote:
> Can you just SetBounds() on |widget_for_highlighting_| instead?

We need to do SetBoundsInScreen so that we can handle highlighting on multiple
displays. Widgets don't have this method. Using SetBoundsInScreen, we can pass
in the display and avoid having a highlight intended for the secondary display
happen instead on the primary display.

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
File ash/common/devtools/ash_devtools_dom_agent.h (right):

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
ash/common/devtools/ash_devtools_dom_agent.h:38: explicit AshDevToolsDOMAgent(
On 2016/12/06 20:48:59, sadrul (OOO) wrote:
> You don't need explicit anymore.

Done.

https://codereview.chromium.org/2542243002/diff/60001/ash/common/devtools/ash...
ash/common/devtools/ash_devtools_dom_agent.h:124: void
UpdateHighlight(std::pair<WmWindow*, gfx::Rect>,
On 2016/12/06 20:48:59, sadrul (OOO) wrote:
> const WindowAndBoundsPair&

Done.

https://codereview.chromium.org/2542243002/diff/60001/ash/common/wm_shell.cc
File ash/common/wm_shell.cc (right):

https://codereview.chromium.org/2542243002/diff/60001/ash/common/wm_shell.cc#...
ash/common/wm_shell.cc:97: this, base::MessageLoop::current()->task_runner());
On 2016/12/06 20:48:59, sadrul (OOO) wrote:
> Use base::ThreadTaskRunnerHandle::Get() instead. But maybe we don't need this?
> See comment in dom-agent.cc

As discussed, passing main_thread_task_runner to devtools_server instead. Agents
no longer know about any task runners.

[commit-bot: I haz the power, 2016-12-07 00:04:22]

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

[commit-bot: I haz the power, 2016-12-07 00:04:23]

Dry run: Try jobs failed on following builders:
  win_chromium_compile_dbg_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_comp...)

[Sarmad Hashmi, 2016-12-07 01:03:56]

Description was changed from

==========
Add hovering feature to AshDevToolsDOMAgent

Hovering over any element in the frontend inspector will now highlight
the corresponding Ash window/widget/view. The highlight and border
color is whatever DevTools provides us in the highlightConfig. Currently,
this is a slightly transparent light blue overlay with a dark yellow
border.

How this is done:
- Create a widget in the primary root window under the OverlayContainer.
- Whenever a node is highlighted, call AshDevToolsDOMAgent::HighlightNode
on the main thread, which then determines where the object is (i.e: bounds)
and what display it is on.
- The parent |window| for the the |widget| that we created will update its
bounds and the |root_view| of the widget has its border/background color
updated to those provided in the highlightConfig.
- When no node is being hovered over, hideHighlight is called by the frontend
and we simply hide the widget.
- We also do not want to show the |widget| in the DOM tree, so if we ever
encounter its parent |window|, it will be ignored.

Minor fix:
- Add UI_DEVTOOLS_EXPORT to static methods in UiDevToolsServer

BUG=648701,669352
==========

to

==========
Add hovering feature to AshDevToolsDOMAgent

Hovering over any element in the frontend inspector will now highlight
the corresponding Ash window/widget/view. The highlight and border
color is whatever DevTools provides us in the highlightConfig. Currently,
this is a slightly transparent light blue overlay with a dark yellow
border.

How this is done:
- Create a widget in the primary root window under the OverlayContainer.
- Whenever a node is highlighted, call AshDevToolsDOMAgent::HighlightNode
on the main thread, which then determines where the object is (i.e: bounds)
and what display it is on.
- The parent |window| for the the |widget| that we created will update its
bounds and the |root_view| of the widget has its border/background color
updated to those provided in the highlightConfig.
- When no node is being hovered over, hideHighlight is called by the frontend
and we simply hide the widget.
- We also do not want to show the |widget| in the DOM tree, so if we ever
encounter its parent |window|, it will be ignored.

BUG=648701
==========

[Sarmad Hashmi, 2016-12-07 01:04:29]

fix for http://crbug.com/669352 causing problems, will solve in another CL.

[sadrul, 2016-12-07 17:37:50]

lgtm

https://codereview.chromium.org/2542243002/diff/120001/ash/common/devtools/as...
File ash/common/devtools/ash_devtools_dom_agent.cc (right):

https://codereview.chromium.org/2542243002/diff/120001/ash/common/devtools/as...
ash/common/devtools/ash_devtools_dom_agent.cc:90: DCHECK_LE(value, 255);
Maybe return (value & 0xff) from here, and use that when creating the
SkColorSetARGB

[Sarmad Hashmi, 2016-12-07 17:57:58]

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

[commit-bot: I haz the power, 2016-12-07 17:58:26]

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-12-07 19:02:54]

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

[commit-bot: I haz the power, 2016-12-07 19:02:55]

Dry run: This issue passed the CQ dry run.

[Sarmad Hashmi, 2016-12-07 21:37:08]

The CQ bit was checked by mhashmi@chromium.org

[Sarmad Hashmi, 2016-12-07 21:37:09]

The patchset sent to the CQ was uploaded after l-g-t-m from sadrul@chromium.org
Link to the patchset: https://codereview.chromium.org/2542243002/#ps140001
(title: "Mask colors when converting RGBA to SkColor")

[commit-bot: I haz the power, 2016-12-07 21:37:48]

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-12-07 21:42:53]

CQ is committing da patch.

Bot data: {"patchset_id": 140001, "attempt_start_ts": 1481146628708540,
"parent_rev": "344925134edb3c081ac0a2a0a0a44f9aa7d53e81", "commit_rev":
"9008bf327bb8a683c65c443e5ead224b3ba2198a"}

[commit-bot: I haz the power, 2016-12-07 21:43:19]

Description was changed from

==========
Add hovering feature to AshDevToolsDOMAgent

Hovering over any element in the frontend inspector will now highlight
the corresponding Ash window/widget/view. The highlight and border
color is whatever DevTools provides us in the highlightConfig. Currently,
this is a slightly transparent light blue overlay with a dark yellow
border.

How this is done:
- Create a widget in the primary root window under the OverlayContainer.
- Whenever a node is highlighted, call AshDevToolsDOMAgent::HighlightNode
on the main thread, which then determines where the object is (i.e: bounds)
and what display it is on.
- The parent |window| for the the |widget| that we created will update its
bounds and the |root_view| of the widget has its border/background color
updated to those provided in the highlightConfig.
- When no node is being hovered over, hideHighlight is called by the frontend
and we simply hide the widget.
- We also do not want to show the |widget| in the DOM tree, so if we ever
encounter its parent |window|, it will be ignored.

BUG=648701
==========

to

==========
Add hovering feature to AshDevToolsDOMAgent

Hovering over any element in the frontend inspector will now highlight
the corresponding Ash window/widget/view. The highlight and border
color is whatever DevTools provides us in the highlightConfig. Currently,
this is a slightly transparent light blue overlay with a dark yellow
border.

How this is done:
- Create a widget in the primary root window under the OverlayContainer.
- Whenever a node is highlighted, call AshDevToolsDOMAgent::HighlightNode
on the main thread, which then determines where the object is (i.e: bounds)
and what display it is on.
- The parent |window| for the the |widget| that we created will update its
bounds and the |root_view| of the widget has its border/background color
updated to those provided in the highlightConfig.
- When no node is being hovered over, hideHighlight is called by the frontend
and we simply hide the widget.
- We also do not want to show the |widget| in the DOM tree, so if we ever
encounter its parent |window|, it will be ignored.

BUG=648701
==========

[commit-bot: I haz the power, 2016-12-07 21:43:20]

Committed patchset #8 (id:140001)

[commit-bot: I haz the power, 2016-12-07 21:47:41]

Description was changed from

==========
Add hovering feature to AshDevToolsDOMAgent

Hovering over any element in the frontend inspector will now highlight
the corresponding Ash window/widget/view. The highlight and border
color is whatever DevTools provides us in the highlightConfig. Currently,
this is a slightly transparent light blue overlay with a dark yellow
border.

How this is done:
- Create a widget in the primary root window under the OverlayContainer.
- Whenever a node is highlighted, call AshDevToolsDOMAgent::HighlightNode
on the main thread, which then determines where the object is (i.e: bounds)
and what display it is on.
- The parent |window| for the the |widget| that we created will update its
bounds and the |root_view| of the widget has its border/background color
updated to those provided in the highlightConfig.
- When no node is being hovered over, hideHighlight is called by the frontend
and we simply hide the widget.
- We also do not want to show the |widget| in the DOM tree, so if we ever
encounter its parent |window|, it will be ignored.

BUG=648701
==========

to

==========
Add hovering feature to AshDevToolsDOMAgent

Hovering over any element in the frontend inspector will now highlight
the corresponding Ash window/widget/view. The highlight and border
color is whatever DevTools provides us in the highlightConfig. Currently,
this is a slightly transparent light blue overlay with a dark yellow
border.

How this is done:
- Create a widget in the primary root window under the OverlayContainer.
- Whenever a node is highlighted, call AshDevToolsDOMAgent::HighlightNode
on the main thread, which then determines where the object is (i.e: bounds)
and what display it is on.
- The parent |window| for the the |widget| that we created will update its
bounds and the |root_view| of the widget has its border/background color
updated to those provided in the highlightConfig.
- When no node is being hovered over, hideHighlight is called by the frontend
and we simply hide the widget.
- We also do not want to show the |widget| in the DOM tree, so if we ever
encounter its parent |window|, it will be ignored.

BUG=648701

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

[commit-bot: I haz the power, 2016-12-07 21:47:42]

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