Notes:

* This can be repro'd by supplying --simulate-upgrade and maximizing / restoring the window.
* This likely happens because the inkdrop uses different insets in restored / maximized mode (so it won't visibly extend to the browser edge even though the clickable area does).
* This affects the upgrade path as the inkdrop remains active even though the window is resized and uses the old insets that are incorrect for the new button size.

Upgrading to P1

This should be fairly infrequent (happens on update request) and goes away when the dialog is dismissed. This would actually take quite a bit of inkdrop restructuring to fix and I don't think we have time to do that for 69. Dropping prio as this should be a low-frequency (esp. for stable) cosmetic thing.

Hey pbos. If the relaunch recommended bubble is the thing that's causing the inkdrop, then you'll need to set the RelaunchNotification policy to 1 (check chrome://policy to see what it is). If you're running a local build, you may as well just edit ReadPreference in relaunch_notification_controller.cc so it unconditionally returns RelaunchNotificationSetting::kRecommendedBubble. Once you've got the policy squared away, launching with --simulate-upgrade (rather than critical-update) should make Chrome think a relaunch is needed for an update, triggering the bubble.

I see some other hits for AnimateInkDrop in this query: https://cs.chromium.org/search/?q=AnimateInkDrop+file:src/chrome/browser&sq=package:chromium&type=cs, so maybe there is an easier way to provoke an inkdrop. I don't know of one off the top of my head.

**UI Mass triage**

Adding appropriate labels based on #14

Issue 669253 has been merged into this issue.