[Mac triage] +a couple of people who might be able to better route this.

 Issue 884791  has been merged into this issue.

We were unable to repro this before. Is anyone with a mac able to dig in? See https://bugs.chromium.org/p/chromium/issues/detail?id=884791#c2 for instructions on making this dialog appear in browser_tests.

As before, I'm stumped. The "Got it" button should lead to RelaunchRequiredDialogView::Cancel, which unconditionally returns true:

https://cs.chromium.org/chromium/src/chrome/browser/ui/views/relaunch_notification/relaunch_required_dialog_view.cc?type=cs&q=RelaunchRequiredDialogView::Cancel+file:%5C.cc&sq=package:chromium&g=0&l=58

On Windows, this is called by DialogClientView::CancelWindow, which right away calls GetWidget()->Close(). Is there any reason why this wouldn't work as expected on macOS?

Tentatively assigning to ellyjones in the hopes that you can ask a macOS dev to take a look. Thanks.

grt@: is there a way to skip the wait in the repro steps? running it via browser_tests might make it behave differently from having it spawn "naturally".

ellyjones@: it's slightly tricky on a corp machine, but doable. check chrome://policy to see that RelaunchNotification is 2. you'll need to find the way that RelaunchNotificationPeriod is given its value (a plist file somewhere?) and set it to 0. then launch chrome with --simulate-upgrade. after maybe 20 seconds you should see the dialog.

I also don't see how this could happen. I applied the following hacks to c/b/ui/v/relaunch_notification/relaunch_notification_controller.cc to make the dialog appear in a chromium build so I could debug:

1) In ReadPreference(), change the default case to return RelaunchNotificationSetting::kRequiredDialog
2) In RelaunchNotificationController::OnUpgradeRecommended(), always set current_level = UpgradeDetector::UPGRADE_ANNOYANCE_HIGH

This causes the dialog to spawn at browser startup (yay!), but I can't repro the behavior described in the bug. :( As far as I can tell, the Cancel path is absolutely standard.

Since this is Mac and the dialog is MODAL_TYPE_WINDOW, this actually is a sheet, which does have a window closure animation that has to run before it disappears. This all happens in BridgedNativeWidgetImpl::CloseWindow(). This code is not well-tested or very heavily used, so it's possible that bugs lurk here, but I can't think of or see anything immediately wrong with it.

Reporter: can we get a screen recording of this behavior?
gab@: are the hacks I did above sensible?

ccing in tapted@ and ccameron@, either of whom might have some guesses here.

Yes, those hacks are perfectly fine. If you see the modal dialog, then the hacks certainly work. :-)

Thank you for taking the time to investigate.