[ios clean] Dismisses ToolsMenu on Layout changes.

ios/clean/chrome/browser/ui/toolbar/toolbar_view_controller.mm

Index: ios/clean/chrome/browser/ui/toolbar/toolbar_view_controller.mm
diff --git a/ios/clean/chrome/browser/ui/toolbar/toolbar_view_controller.mm b/ios/clean/chrome/browser/ui/toolbar/toolbar_view_controller.mm
index 48003841e5e842087ebc234347379bafe143ab22..7d533e1db8fcc310dc5867f60614931a1aa4bbf4 100644
--- a/ios/clean/chrome/browser/ui/toolbar/toolbar_view_controller.mm
+++ b/ios/clean/chrome/browser/ui/toolbar/toolbar_view_controller.mm
@@ -59,6 +59,8 @@ CGFloat kHorizontalMargin = 8.0f;
   return self;
 }
 
+#pragma mark - View lifecyle
+
 - (void)viewDidLoad {
   self.view.backgroundColor = [UIColor lightGrayColor];
 
@@ -94,6 +96,12 @@ CGFloat kHorizontalMargin = 8.0f;
   ]];
 }
 
+- (void)viewWillLayoutSubviews {
+  // We need to dismiss the ToolsMenu everytime the Toolbar position changes
+  // (e.g. Size changes, rotation changes, etc.)
+  [self.dispatcher closeToolsMenu];

[marq (ping after 24h), 2017/05/09 12:13:26]

I'm pretty sure this isn't what we want. What if setCanGoForward:NO is called by
the mediator while the menu is showing? That will cause the forward button to
hide, which will trigger a layout pass, which will dismiss the tools menu.

[sczs, 2017/05/10 02:25:46]

Completely right, thanks for pointing this out. I tried a couple of things but I
think checking if the frame changed is our best bet all things considered.

I also tried setting a flag for Toolbar Button visibility changes, but any new
component would still trigger the dismissal. I think the approach I chose is the
most maintainable. 

+}
+
 #pragma mark - Components Setup
 
 - (void)setUpToolbarButtons {