Close holding space bubble when hiding holding space tray.

It was previously assumed (at least by me) that hiding the holding
space tray would result in closing of the holding space bubble. This
was not actually guaranteed to be the case. This means that it was
theoretically possible to keep the holding space bubble open even after
detaching the holding space model and client, though I have not been
able to reproduce this in the real world w/o forcing state
programmatically. It's possible that a user was able to reach such a
state which could result in the crash in the attached bug if interacting
with the Files app chip.

Bug: 1165305
Change-Id: I039072d2d07eaf741ae70d551ac7889eaee0a46c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2623726Reviewed-by: Toni Baržić <tbarzic@chromium.org>
Commit-Queue: David Black <dmblack@google.com>
Cr-Commit-Position: refs/heads/master@{#842636}

ash/system/holding_space/holding_space_tray.cc

@@ -192,13 +192,18 @@ TrayBubbleView* HoldingSpaceTray::GetBubbleView() {
   return bubble_ ? bubble_->GetBubbleView() : nullptr;
 }
 
-void HoldingSpaceTray::SetVisiblePreferred(bool preferred_visibility) {
-  if (visible_preferred() != preferred_visibility) {
-    holding_space_metrics::RecordPodAction(
-        preferred_visibility ? holding_space_metrics::PodAction::kShowPod
-                             : holding_space_metrics::PodAction::kHidePod);
-    TrayBackgroundView::SetVisiblePreferred(preferred_visibility);
-  }
+void HoldingSpaceTray::SetVisiblePreferred(bool visible_preferred) {
+  if (this->visible_preferred() == visible_preferred)
+    return;
+
+  holding_space_metrics::RecordPodAction(
+      visible_preferred ? holding_space_metrics::PodAction::kShowPod
+                        : holding_space_metrics::PodAction::kHidePod);
+
+  TrayBackgroundView::SetVisiblePreferred(visible_preferred);
+
+  if (!visible_preferred)
+    CloseBubble();
 }
 
 void HoldingSpaceTray::FirePreviewsUpdateTimerIfRunningForTesting() {