Move shelf item tooltip flag from delegate to item.

Move shelf item tooltip flag from delegate to item.

Remove ShelfItemDelegate::ShouldShowTooltip and overrides.
Add ShelfItem::shows_tooltip and plumbing, update users.

Remove WindowState panel-attached member and accessors.
Add ash, mus, and common panel-attached property keys.

Add requisite WmWindow::SetBoolProperty and aura impl.
Add requisite ShelfItem copy ctor (compiler complained...)

BUG=557406
TEST=No Chrome OS shelf tooltip (or panel) behavior changes.
R=sky@chromium.org
TBR=tsepez@chromium.org

Committed: https://crrev.com/60fee0810363cb1c3826ca3d375208bd4805aef3
Cr-Commit-Position: refs/heads/master@{#437441}

[msw, 2016-12-07 22:36:26]

Description was changed from

==========
Move shelf item tooltip flag from delegate to item.

BUG=557406
==========

to

==========
Move shelf item tooltip flag from delegate to item.

Remove ShelfItemDelegate::ShouldShowTooltip and overrides.
Add ShelfItem::shows_tooltip and plumbing, update users.

Remove WindowState panel-attached member and accessors.
Add ash, mus, and common panel-attached property keys.

Add requisite WmWindow::SetBoolProperty and aura impl.
Add requisite ShelfItem copy ctor (compiler complained...)

BUG=557406
TEST=No Chrome OS shelf tooltip (or panel) behavior changes.
R=sky@chromium.org
==========

[msw, 2016-12-07 22:36:26]

msw@chromium.org changed reviewers:
+ sky@chromium.org

[msw, 2016-12-07 22:36:37]

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

[commit-bot: I haz the power, 2016-12-07 22:37:11]

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

[msw, 2016-12-07 23:20:56]

Hey Scott, please take a look; thanks!

[commit-bot: I haz the power, 2016-12-07 23:56:58]

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

[commit-bot: I haz the power, 2016-12-07 23:56:59]

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

[sky, 2016-12-08 00:38:53]

sky@chromium.org changed reviewers:
+ oshima@chromium.org

[sky, 2016-12-08 00:38:54]

+oshima for question about moving WmState::panel_attached to a property.

https://codereview.chromium.org/2558963002/diff/20001/ash/aura/wm_window_aura.cc
File ash/aura/wm_window_aura.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/aura/wm_window_aura...
ash/aura/wm_window_aura.cc:313: void
WmWindowAura::SetBoolProperty(WmWindowProperty key, bool value) {
Do we really need to set all these properties? I believe when I looked into
these properties I never saw us explicitly setting them via property.

https://codereview.chromium.org/2558963002/diff/20001/ash/aura/wm_window_aura...
ash/aura/wm_window_aura.cc:316:
window_->SetProperty(aura::client::kDrawAttentionKey, value);
I am tempted to say you should just route through aura::Window now (meaning add
an aura_window() accessor to WmWindow and change code to start using it), but I
really need to think about the best way to unravel all this code.

https://codereview.chromium.org/2558963002/diff/20001/ash/common/shelf/shelf_...
File ash/common/shelf/shelf_item_types.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/common/shelf/shelf_...
ash/common/shelf/shelf_item_types.cc:11: ShelfItem::ShelfItem(const ShelfItem&
shelf_item)
Can this = default?

https://codereview.chromium.org/2558963002/diff/20001/ash/common/shelf/shelf_...
File ash/common/shelf/shelf_window_watcher.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/common/shelf/shelf_...
ash/common/shelf/shelf_window_watcher.cc:44: item->type != TYPE_APP_PANEL ||
!window->IsVisible() ||
Do we always end up back in this function when the visibility changes?

https://codereview.chromium.org/2558963002/diff/20001/ash/common/wm_window_pr...
File ash/common/wm_window_property.h (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/common/wm_window_pr...
ash/common/wm_window_property.h:52: PANEL_ATTACHED,
optional: keep sorted (but really not that important as I'm hoping this file
goes away soon).

https://codereview.chromium.org/2558963002/diff/20001/ash/mus/bridge/wm_windo...
File ash/mus/bridge/wm_window_mus.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/mus/bridge/wm_windo...
ash/mus/bridge/wm_window_mus.cc:139: void
WmWindowMus::SetBoolProperty(WmWindowProperty key, bool value) {
Do we really need the override? Can't we use the implementation in WmWindowAura?

https://codereview.chromium.org/2558963002/diff/20001/ash/wm/panels/panel_win...
File ash/wm/panels/panel_window_resizer_unittest.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/wm/panels/panel_win...
ash/wm/panels/panel_window_resizer_unittest.cc:330:
EXPECT_FALSE(window->GetProperty(kPanelAttachedKey));
I think Oshima explicitly wanted state information to be encapsulated in
WmState. It's ok to have WmState call out to get a property, but everyone but
WmState should go through WmState. I'll add Oshima to this review for his input
to see if I have that right.

[msw, 2016-12-08 20:31:36]

Hey Oshima, please see the panel_window_resizer_unittest.cc thread.

https://codereview.chromium.org/2558963002/diff/20001/ash/aura/wm_window_aura.cc
File ash/aura/wm_window_aura.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/aura/wm_window_aura...
ash/aura/wm_window_aura.cc:313: void
WmWindowAura::SetBoolProperty(WmWindowProperty key, bool value) {
On 2016/12/08 00:38:54, sky wrote:
> Do we really need to set all these properties? I believe when I looked into
> these properties I never saw us explicitly setting them via property.

Reduced to just panel_attached; I was just matching the set from Get.

https://codereview.chromium.org/2558963002/diff/20001/ash/aura/wm_window_aura...
ash/aura/wm_window_aura.cc:316:
window_->SetProperty(aura::client::kDrawAttentionKey, value);
On 2016/12/08 00:38:54, sky wrote:
> I am tempted to say you should just route through aura::Window now (meaning
add
> an aura_window() accessor to WmWindow and change code to start using it), but
I
> really need to think about the best way to unravel all this code.

We need lots of ash/common cleanup... I'd opt to leave it out of this CL.

https://codereview.chromium.org/2558963002/diff/20001/ash/common/shelf/shelf_...
File ash/common/shelf/shelf_item_types.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/common/shelf/shelf_...
ash/common/shelf/shelf_item_types.cc:11: ShelfItem::ShelfItem(const ShelfItem&
shelf_item)
On 2016/12/08 00:38:54, sky wrote:
> Can this = default?

Done. Good call, thanks! Aside: I wonder why adding a bool suddenly make this
struct complex?

https://codereview.chromium.org/2558963002/diff/20001/ash/common/shelf/shelf_...
File ash/common/shelf/shelf_window_watcher.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/common/shelf/shelf_...
ash/common/shelf/shelf_window_watcher.cc:44: item->type != TYPE_APP_PANEL ||
!window->IsVisible() ||
On 2016/12/08 00:38:54, sky wrote:
> Do we always end up back in this function when the visibility changes?

This was just working by chance, because minimizing/restoring (or closing)
panels seem to be the only way to change their visibility, and that was also
changing their activation. I wired up WmWindowObserver::OnVisibilityChanged to
this function. It seems like that might add some wasteful no-ops for children
and ancestors of observed user windows, but I don't know how much that really
matters, nor do I have any great ideas to avoid that.

https://codereview.chromium.org/2558963002/diff/20001/ash/common/wm_window_pr...
File ash/common/wm_window_property.h (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/common/wm_window_pr...
ash/common/wm_window_property.h:52: PANEL_ATTACHED,
On 2016/12/08 00:38:54, sky wrote:
> optional: keep sorted (but really not that important as I'm hoping this file
> goes away soon).

Done.

https://codereview.chromium.org/2558963002/diff/20001/ash/mus/bridge/wm_windo...
File ash/mus/bridge/wm_window_mus.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/mus/bridge/wm_windo...
ash/mus/bridge/wm_window_mus.cc:139: void
WmWindowMus::SetBoolProperty(WmWindowProperty key, bool value) {
On 2016/12/08 00:38:54, sky wrote:
> Do we really need the override? Can't we use the implementation in
WmWindowAura?

Would that work? I'm not sure it matters; isn't this code [soon to be] dead?

https://codereview.chromium.org/2558963002/diff/20001/ash/wm/panels/panel_win...
File ash/wm/panels/panel_window_resizer_unittest.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/wm/panels/panel_win...
ash/wm/panels/panel_window_resizer_unittest.cc:330:
EXPECT_FALSE(window->GetProperty(kPanelAttachedKey));
On 2016/12/08 00:38:54, sky wrote:
> I think Oshima explicitly wanted state information to be encapsulated in
> WmState. It's ok to have WmState call out to get a property, but everyone but
> WmState should go through WmState. I'll add Oshima to this review for his
input
> to see if I have that right.

I'm eager to hear more about the reasoning for that. It seems more difficult to
propagate the whole wm::WindowState property for aura-mus (we'd need a matching
mojo struct and converter), versus using a handful of individual window
properties. It also seems more difficult to observe changes to wm::WindowState
members (there's no OnWindowStateChanged, WindowStateObserver looks rather
incomplete, and I wonder why we'd want to split window observation from state
observation, and where to draw that line, eg. would it make sense to call
WindowObserver::OnWindowStatechanged or
WindowStateObserver::OnPanelAttachedChanged anytime this flag changes?).

It looks like a lot of wm::WindowState mirrors what's on aura::Window, and
simultaneously, wm::WindowState doesn't seem to capture everything needed to
represent the state of a window (eg. title?), some of its purpose is lost on me.

Abstractly, this seems like the difference between keeping numerous simple
window properties versus keeping a single complex window property that
represents a wide array of aspects regarding window state... I can see that the
latter might help for certain things (storing and reverting a set of properties
that depend on the completion/cancellation of a drag), but in general, it seems
like keeping state information as window properties makes more sense to me.

Oshima, can you weigh in? Perhaps we don't need an overarching plan if moving
this one flag to a window property (for now) is alright.

[msw, 2016-12-08 20:52:16]

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

[sky, 2016-12-08 20:52:42]

https://codereview.chromium.org/2558963002/diff/20001/ash/mus/bridge/wm_windo...
File ash/mus/bridge/wm_window_mus.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/mus/bridge/wm_windo...
ash/mus/bridge/wm_window_mus.cc:139: void
WmWindowMus::SetBoolProperty(WmWindowProperty key, bool value) {
On 2016/12/08 20:31:36, msw wrote:
> On 2016/12/08 00:38:54, sky wrote:
> > Do we really need the override? Can't we use the implementation in
> WmWindowAura?
> 
> Would that work? I'm not sure it matters; isn't this code [soon to be] dead?

It should work, because the property is registered with the PropertyConverter,
right? Maybe I'm missing something?

https://codereview.chromium.org/2558963002/diff/20001/ash/wm/panels/panel_win...
File ash/wm/panels/panel_window_resizer_unittest.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/wm/panels/panel_win...
ash/wm/panels/panel_window_resizer_unittest.cc:330:
EXPECT_FALSE(window->GetProperty(kPanelAttachedKey));
On 2016/12/08 20:31:36, msw wrote:
> On 2016/12/08 00:38:54, sky wrote:
> > I think Oshima explicitly wanted state information to be encapsulated in
> > WmState. It's ok to have WmState call out to get a property, but everyone
but
> > WmState should go through WmState. I'll add Oshima to this review for his
> input
> > to see if I have that right.
> 
> I'm eager to hear more about the reasoning for that. It seems more difficult
to
> propagate the whole wm::WindowState property for aura-mus (we'd need a
matching
> mojo struct and converter), versus using a handful of individual window
> properties. It also seems more difficult to observe changes to wm::WindowState
> members (there's no OnWindowStateChanged, WindowStateObserver looks rather
> incomplete, and I wonder why we'd want to split window observation from state
> observation, and where to draw that line, eg. would it make sense to call
> WindowObserver::OnWindowStatechanged or
> WindowStateObserver::OnPanelAttachedChanged anytime this flag changes?).
> 
> It looks like a lot of wm::WindowState mirrors what's on aura::Window, and
> simultaneously, wm::WindowState doesn't seem to capture everything needed to
> represent the state of a window (eg. title?), some of its purpose is lost on
me.
> 
> Abstractly, this seems like the difference between keeping numerous simple
> window properties versus keeping a single complex window property that
> represents a wide array of aspects regarding window state... I can see that
the
> latter might help for certain things (storing and reverting a set of
properties
> that depend on the completion/cancellation of a drag), but in general, it
seems
> like keeping state information as window properties makes more sense to me.
> 
> Oshima, can you weigh in? Perhaps we don't need an overarching plan if moving
> this one flag to a window property (for now) is alright.

I'm going to leave Oshima to answer this one.

[commit-bot: I haz the power, 2016-12-08 20:52:53]

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

[msw, 2016-12-08 21:00:21]

https://codereview.chromium.org/2558963002/diff/20001/ash/mus/bridge/wm_windo...
File ash/mus/bridge/wm_window_mus.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/mus/bridge/wm_windo...
ash/mus/bridge/wm_window_mus.cc:139: void
WmWindowMus::SetBoolProperty(WmWindowProperty key, bool value) {
On 2016/12/08 20:52:42, sky wrote:
> On 2016/12/08 20:31:36, msw wrote:
> > On 2016/12/08 00:38:54, sky wrote:
> > > Do we really need the override? Can't we use the implementation in
> > WmWindowAura?
> > 
> > Would that work? I'm not sure it matters; isn't this code [soon to be] dead?
> 
> It should work, because the property is registered with the PropertyConverter,
> right? Maybe I'm missing something?

I guess I'm not sure what you have in mind here, I thought you meant calling
WmWindowAura::SetBoolProperty here (somehow) or making this function not virtual
and defining WmWindow::SetBoolProperty, but now I think you might mean something
else. What's the problem with leaving this unimplemented? WmWindowMus is going
away as soon as possible after switching mash to aura-mus, right? Sorry if I'm
misunderstanding.

[msw, 2016-12-08 21:18:19]

https://codereview.chromium.org/2558963002/diff/20001/ash/mus/bridge/wm_windo...
File ash/mus/bridge/wm_window_mus.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/mus/bridge/wm_windo...
ash/mus/bridge/wm_window_mus.cc:139: void
WmWindowMus::SetBoolProperty(WmWindowProperty key, bool value) {
On 2016/12/08 21:00:21, msw wrote:
> On 2016/12/08 20:52:42, sky wrote:
> > On 2016/12/08 20:31:36, msw wrote:
> > > On 2016/12/08 00:38:54, sky wrote:
> > > > Do we really need the override? Can't we use the implementation in
> > > WmWindowAura?
> > > 
> > > Would that work? I'm not sure it matters; isn't this code [soon to be]
dead?
> > 
> > It should work, because the property is registered with the
PropertyConverter,
> > right? Maybe I'm missing something?
> 
> I guess I'm not sure what you have in mind here, I thought you meant calling
> WmWindowAura::SetBoolProperty here (somehow) or making this function not
virtual
> and defining WmWindow::SetBoolProperty, but now I think you might mean
something
> else. What's the problem with leaving this unimplemented? WmWindowMus is going
> away as soon as possible after switching mash to aura-mus, right? Sorry if I'm
> misunderstanding.

Done. Thanks for explaining offline that WmWindowMus is a WmWindowAura.

[msw, 2016-12-08 21:18:27]

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

[commit-bot: I haz the power, 2016-12-08 21:19:03]

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-08 23:01:37]

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

[commit-bot: I haz the power, 2016-12-08 23:01:38]

Dry run: This issue passed the CQ dry run.

[sky, 2016-12-08 23:08:30]

LGTM

[msw, 2016-12-09 01:18:21]

https://codereview.chromium.org/2558963002/diff/20001/ash/wm/panels/panel_win...
File ash/wm/panels/panel_window_resizer_unittest.cc (right):

https://codereview.chromium.org/2558963002/diff/20001/ash/wm/panels/panel_win...
ash/wm/panels/panel_window_resizer_unittest.cc:330:
EXPECT_FALSE(window->GetProperty(kPanelAttachedKey));
On 2016/12/08 20:52:42, sky wrote:
> On 2016/12/08 20:31:36, msw wrote:
> > On 2016/12/08 00:38:54, sky wrote:
> > > I think Oshima explicitly wanted state information to be encapsulated in
> > > WmState. It's ok to have WmState call out to get a property, but everyone
> but
> > > WmState should go through WmState. I'll add Oshima to this review for his
> > input
> > > to see if I have that right.
> > 
> > I'm eager to hear more about the reasoning for that. It seems more difficult
> to
> > propagate the whole wm::WindowState property for aura-mus (we'd need a
> matching
> > mojo struct and converter), versus using a handful of individual window
> > properties. It also seems more difficult to observe changes to
wm::WindowState
> > members (there's no OnWindowStateChanged, WindowStateObserver looks rather
> > incomplete, and I wonder why we'd want to split window observation from
state
> > observation, and where to draw that line, eg. would it make sense to call
> > WindowObserver::OnWindowStatechanged or
> > WindowStateObserver::OnPanelAttachedChanged anytime this flag changes?).
> > 
> > It looks like a lot of wm::WindowState mirrors what's on aura::Window, and
> > simultaneously, wm::WindowState doesn't seem to capture everything needed to
> > represent the state of a window (eg. title?), some of its purpose is lost on
> me.
> > 
> > Abstractly, this seems like the difference between keeping numerous simple
> > window properties versus keeping a single complex window property that
> > represents a wide array of aspects regarding window state... I can see that
> the
> > latter might help for certain things (storing and reverting a set of
> properties
> > that depend on the completion/cancellation of a drag), but in general, it
> seems
> > like keeping state information as window properties makes more sense to me.
> > 
> > Oshima, can you weigh in? Perhaps we don't need an overarching plan if
moving
> > this one flag to a window property (for now) is alright.
> 
> I'm going to leave Oshima to answer this one.

Oshima and I chatted over im; he doesn't have any objections. He noted that
wm::WindowState is better for ash/wm-specific state, but that's not a strict
rule, and panels are going away soon anyway.

[msw, 2016-12-09 01:18:29]

The CQ bit was checked by msw@chromium.org

[commit-bot: I haz the power, 2016-12-09 01:19:15]

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-09 02:14:56]

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

[commit-bot: I haz the power, 2016-12-09 02:14:58]

Try jobs failed on following builders:
  chromium_presubmit on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[msw, 2016-12-09 02:23:05]

Description was changed from

==========
Move shelf item tooltip flag from delegate to item.

Remove ShelfItemDelegate::ShouldShowTooltip and overrides.
Add ShelfItem::shows_tooltip and plumbing, update users.

Remove WindowState panel-attached member and accessors.
Add ash, mus, and common panel-attached property keys.

Add requisite WmWindow::SetBoolProperty and aura impl.
Add requisite ShelfItem copy ctor (compiler complained...)

BUG=557406
TEST=No Chrome OS shelf tooltip (or panel) behavior changes.
R=sky@chromium.org
==========

to

==========
Move shelf item tooltip flag from delegate to item.

Remove ShelfItemDelegate::ShouldShowTooltip and overrides.
Add ShelfItem::shows_tooltip and plumbing, update users.

Remove WindowState panel-attached member and accessors.
Add ash, mus, and common panel-attached property keys.

Add requisite WmWindow::SetBoolProperty and aura impl.
Add requisite ShelfItem copy ctor (compiler complained...)

BUG=557406
TEST=No Chrome OS shelf tooltip (or panel) behavior changes.
R=sky@chromium.org
TBR=tsepez@chromium.org
==========

[msw, 2016-12-09 02:23:05]

msw@chromium.org changed reviewers:
+ tsepez@chromium.org

[msw, 2016-12-09 02:23:44]

+TBR Tom for window_manager.mojom; ptal as you have time, thanks!

[msw, 2016-12-09 02:23:53]

The CQ bit was checked by msw@chromium.org

[commit-bot: I haz the power, 2016-12-09 02:24:21]

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-09 02:36:17]

CQ is committing da patch.

Bot data: {"patchset_id": 80001, "attempt_start_ts": 1481250233137600,
"parent_rev": "65dda036879152165797e0a5a84b7ecf67079209", "commit_rev":
"600505f4ac47c5929ec4a958e5b0671f723edc90"}

[commit-bot: I haz the power, 2016-12-09 02:36:45]

Description was changed from

==========
Move shelf item tooltip flag from delegate to item.

Remove ShelfItemDelegate::ShouldShowTooltip and overrides.
Add ShelfItem::shows_tooltip and plumbing, update users.

Remove WindowState panel-attached member and accessors.
Add ash, mus, and common panel-attached property keys.

Add requisite WmWindow::SetBoolProperty and aura impl.
Add requisite ShelfItem copy ctor (compiler complained...)

BUG=557406
TEST=No Chrome OS shelf tooltip (or panel) behavior changes.
R=sky@chromium.org
TBR=tsepez@chromium.org
==========

to

==========
Move shelf item tooltip flag from delegate to item.

Remove ShelfItemDelegate::ShouldShowTooltip and overrides.
Add ShelfItem::shows_tooltip and plumbing, update users.

Remove WindowState panel-attached member and accessors.
Add ash, mus, and common panel-attached property keys.

Add requisite WmWindow::SetBoolProperty and aura impl.
Add requisite ShelfItem copy ctor (compiler complained...)

BUG=557406
TEST=No Chrome OS shelf tooltip (or panel) behavior changes.
R=sky@chromium.org
TBR=tsepez@chromium.org
==========

[commit-bot: I haz the power, 2016-12-09 02:36:46]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-12-09 02:38:53]

Description was changed from

==========
Move shelf item tooltip flag from delegate to item.

Remove ShelfItemDelegate::ShouldShowTooltip and overrides.
Add ShelfItem::shows_tooltip and plumbing, update users.

Remove WindowState panel-attached member and accessors.
Add ash, mus, and common panel-attached property keys.

Add requisite WmWindow::SetBoolProperty and aura impl.
Add requisite ShelfItem copy ctor (compiler complained...)

BUG=557406
TEST=No Chrome OS shelf tooltip (or panel) behavior changes.
R=sky@chromium.org
TBR=tsepez@chromium.org
==========

to

==========
Move shelf item tooltip flag from delegate to item.

Remove ShelfItemDelegate::ShouldShowTooltip and overrides.
Add ShelfItem::shows_tooltip and plumbing, update users.

Remove WindowState panel-attached member and accessors.
Add ash, mus, and common panel-attached property keys.

Add requisite WmWindow::SetBoolProperty and aura impl.
Add requisite ShelfItem copy ctor (compiler complained...)

BUG=557406
TEST=No Chrome OS shelf tooltip (or panel) behavior changes.
R=sky@chromium.org
TBR=tsepez@chromium.org

Committed: https://crrev.com/60fee0810363cb1c3826ca3d375208bd4805aef3
Cr-Commit-Position: refs/heads/master@{#437441}
==========

[commit-bot: I haz the power, 2016-12-09 02:38:54]

Patchset 5 (id:??) landed as
https://crrev.com/60fee0810363cb1c3826ca3d375208bd4805aef3
Cr-Commit-Position: refs/heads/master@{#437441}