Ben, WDYT?

I agree that the TriView should automatically re-layout it's children when a container view's visibility changes.  However, I think we need to be careful about how the TriView itself behaves during this re-layout. i.e. I don't think the TriView itself should change size in some cases.

For example, imagine a TriView that has all 3 containers visible and a Label in the center container is wrapped to be 6 lines high.  If you change the START container to not be visible anymore, it is possible that the Label now only requires, say, 4 lines, which may change the preferred size of the TriView itself.  I don't think we want the rows of the SystemMenu to change in this case.

Ideally, the TriView size changing would be easily configurable and obvious to the TriView clients but I'm not sure if this is a feature change to TriView itself or to the layout code allocating the TriViews size...

So to be a bit more concrete, what do you think the correct behavior would be for the TODO in VolumeView::UpdateDeviceTypeAndMore() ?

I don't think the size of the VolumeView row should change. This shouldn't happen for the VolumeView case but in general it could happen for TriViews that have multiline labels or some other height changing View in a different container.

If we wanted to address the general case there are 2 ways I can think of to do this...

The quick fix, aka workaround IMO:

- Make TriView re-layout it's children
- TriView would cache it's preferred size when it is visible and only update/propagate it when not visible
(Maybe this behavior could even be pushed into View's default SetPreferredSize() function...)

More general solution:
- Make TriView relayout it's children
- TriView would propagate it's new preferred size if it has changed
- The parent View and/or Layout manager would be configured to NOT re-layout the TriView if it was visible AND it would make sure any subsequent Layouts would use the initial preferred size of the TriView not the new preferred size.
This is clearly more invasive and more work.

CL: https://codereview.chromium.org/2932053003/

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/063c6c51120102374631bd44e180511e8e076670

commit 063c6c51120102374631bd44e180511e8e076670
Author: bruthig <bruthig@chromium.org>
Date: Fri Jun 09 21:21:15 2017

[ash] Made TriView's re-layout automatically when a child container's visibility changes.

BUG= 720581 
TEST=ash_unittests --gtest_filter=TriViewTest*

Review-Url: https://codereview.chromium.org/2932053003
Cr-Commit-Position: refs/heads/master@{#478418}

[modify] https://crrev.com/063c6c51120102374631bd44e180511e8e076670/ash/system/audio/volume_view.cc
[modify] https://crrev.com/063c6c51120102374631bd44e180511e8e076670/ash/system/tray/tri_view.cc
[modify] https://crrev.com/063c6c51120102374631bd44e180511e8e076670/ash/system/tray/tri_view.h
[modify] https://crrev.com/063c6c51120102374631bd44e180511e8e076670/ash/system/tray/tri_view_unittest.cc