[reland] MacViews: Allow the toolkit-views Enterprise Signin Confirmation Dialog to be used

[reland] MacViews: Allow the toolkit-views Enterprise Signin Confirmation Dialog to be used

Previously reviewed in https://codereview.chromium.org/2625813003.
Reverted due to Win10 failures http://crbug.com/683808. Fix in r447216.

The toolkit-views dialog will be used when --secondary-ui-md is enabled.

(With that flag) The dialog also becomes window-modal on Mac, rather
than tab-modal. This is consistent with other platforms. That's the easy
bit -- ProfileSigninConfirmationDialogViews::ShowDialog() "Just Works".

Adds a browser_test for showing the views dialog - it had no prior
coverage. Uses the fix in r447216 to detect these "transient" child
windows.

Also, there was a memory leak.
OneClickSigninSyncStarter::OnRegisteredForPolicy() allocated a
SigninDialogDelegate with `new` which was never released. Cocoa tests in
profile_signin_confirmation_view_controller_browsertest.mm didn't pick
this up because the tests use the test harness as the delegate (passing
`this`). The right fix is to pass a std::unique_ptr - do that.

BUG=681049
Review-Url: https://codereview.chromium.org/2625813003

Review-Url: https://codereview.chromium.org/2667773003
Cr-Commit-Position: refs/heads/master@{#449485}
Committed: https://chromium.googlesource.com/chromium/src/+/3d35b33c364f4a5b8872b96b73dfa72f6ec64921

[tapted, 2017-01-31 11:18:37]

The CQ bit was checked by tapted@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-31 11:18:43]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[tapted, 2017-01-31 11:19:30]

Description was changed from

==========
[reland] MacViews: Allow the toolkit-views Enterprise Signin Confirmation Dialog
to be used

Previously reviewed in https://codereview.chromium.org/2625813003.
Reverted due to Win10 failures (http://crbug.com/683808). Fixed in r447216.

The toolkit-views dialog will be used when --secondary-ui-md is enabled.

(With that flag) The dialog also becomes window-modal on Mac, rather
than tab-modal. This is consistent with other platforms. That's the easy
bit -- ProfileSigninConfirmationDialogViews::ShowDialog() "Just Works".

Adds a browser_test for showing the views dialog - it had no prior
coverage. Uses the fix in r447216 to detect these "transient" child windows.

Also, there was a memory leak.
OneClickSigninSyncStarter::OnRegisteredForPolicy() allocated a
SigninDialogDelegate with `new` which was never released. Cocoa tests in
profile_signin_confirmation_view_controller_browsertest.mm didn't pick
this up because the tests use the test harness as the delegate (passing
`this`). The right fix is to pass a std::unique_ptr - do that.

BUG=681049
Review-Url: https://codereview.chromium.org/2625813003
==========

to

==========
[reland] MacViews: Allow the toolkit-views Enterprise Signin Confirmation Dialog
to be used

Previously reviewed in https://codereview.chromium.org/2625813003.
Reverted due to Win10 failures http://crbug.com/683808. Fix in r447216.

The toolkit-views dialog will be used when --secondary-ui-md is enabled.

(With that flag) The dialog also becomes window-modal on Mac, rather
than tab-modal. This is consistent with other platforms. That's the easy
bit -- ProfileSigninConfirmationDialogViews::ShowDialog() "Just Works".

Adds a browser_test for showing the views dialog - it had no prior
coverage. Uses the fix in r447216 to detect these "transient" child
windows.

Also, there was a memory leak.
OneClickSigninSyncStarter::OnRegisteredForPolicy() allocated a
SigninDialogDelegate with `new` which was never released. Cocoa tests in
profile_signin_confirmation_view_controller_browsertest.mm didn't pick
this up because the tests use the test harness as the delegate (passing
`this`). The right fix is to pass a std::unique_ptr - do that.

BUG=681049 Review-Url: https://codereview.chromium.org/2625813003
==========

[commit-bot: I haz the power, 2017-01-31 11:34:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-31 11:34:09]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[tapted, 2017-01-31 23:48:22]

The CQ bit was checked by tapted@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-31 23:49:10]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-01 01:41:58]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-01 01:41:58]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[tapted, 2017-02-09 06:03:24]

The CQ bit was checked by tapted@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-09 06:03:46]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-09 07:45:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-09 07:45:52]

Dry run: This issue passed the CQ dry run.

[tapted, 2017-02-09 08:54:37]

tapted@chromium.org changed reviewers:
+ msw@chromium.org

[tapted, 2017-02-09 08:54:38]

Hi Mike, please take a look. This is already reviewed, but it was reverted a
while ago, so I made a new CL. There are actually no changes from the other CL
apart from a rebase, which needed some #include tweaks. One source file drops
off (chrome/browser/ui/test/test_browser_dialog.cc) since the fixes it needed
(to fix the cause of the revert) have landed already.

Thanks!

[msw, 2017-02-09 18:09:55]

lgtm with a minor comment nit

https://codereview.chromium.org/2667773003/diff/40001/chrome/browser/ui/views...
File
chrome/browser/ui/views/sync/profile_signin_confirmation_dialog_views_browsertest.cc
(right):

https://codereview.chromium.org/2667773003/diff/40001/chrome/browser/ui/views...
chrome/browser/ui/views/sync/profile_signin_confirmation_dialog_views_browsertest.cc:21:
// Test delegate passed to the confirmation dialog to report back the result.
nit: "to report back the result"? Seems like this does nothing?

[tapted, 2017-02-09 23:16:10]

https://codereview.chromium.org/2667773003/diff/40001/chrome/browser/ui/views...
File
chrome/browser/ui/views/sync/profile_signin_confirmation_dialog_views_browsertest.cc
(right):

https://codereview.chromium.org/2667773003/diff/40001/chrome/browser/ui/views...
chrome/browser/ui/views/sync/profile_signin_confirmation_dialog_views_browsertest.cc:21:
// Test delegate passed to the confirmation dialog to report back the result.
On 2017/02/09 18:09:54, msw wrote:
> nit: "to report back the result"? Seems like this does nothing?

ah, it allows the dialog to report. Or the delegate to receive the result :). I
agree the current wording is confusing - updated to:

// Test delegate passed to the confirmation dialog to receive (and currently
// ignore) the result from the dialog.

[tapted, 2017-02-09 23:16:17]

The CQ bit was checked by tapted@chromium.org

[tapted, 2017-02-09 23:16:18]

The patchset sent to the CQ was uploaded after l-g-t-m from msw@chromium.org
Link to the patchset: https://codereview.chromium.org/2667773003/#ps60001
(title: "clearer comment")

[commit-bot: I haz the power, 2017-02-09 23:16:42]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-10 00:17:31]

CQ is committing da patch.

Bot data: {"patchset_id": 60001, "attempt_start_ts": 1486682177863510,
"parent_rev": "c841b76ac7d8465283eb13e87d05388004a6f6bf", "commit_rev":
"3d35b33c364f4a5b8872b96b73dfa72f6ec64921"}

[commit-bot: I haz the power, 2017-02-10 00:18:07]

Description was changed from

==========
[reland] MacViews: Allow the toolkit-views Enterprise Signin Confirmation Dialog
to be used

Previously reviewed in https://codereview.chromium.org/2625813003.
Reverted due to Win10 failures http://crbug.com/683808. Fix in r447216.

The toolkit-views dialog will be used when --secondary-ui-md is enabled.

(With that flag) The dialog also becomes window-modal on Mac, rather
than tab-modal. This is consistent with other platforms. That's the easy
bit -- ProfileSigninConfirmationDialogViews::ShowDialog() "Just Works".

Adds a browser_test for showing the views dialog - it had no prior
coverage. Uses the fix in r447216 to detect these "transient" child
windows.

Also, there was a memory leak.
OneClickSigninSyncStarter::OnRegisteredForPolicy() allocated a
SigninDialogDelegate with `new` which was never released. Cocoa tests in
profile_signin_confirmation_view_controller_browsertest.mm didn't pick
this up because the tests use the test harness as the delegate (passing
`this`). The right fix is to pass a std::unique_ptr - do that.

BUG=681049 Review-Url: https://codereview.chromium.org/2625813003
==========

to

==========
[reland] MacViews: Allow the toolkit-views Enterprise Signin Confirmation Dialog
to be used

Previously reviewed in https://codereview.chromium.org/2625813003.
Reverted due to Win10 failures http://crbug.com/683808. Fix in r447216.

The toolkit-views dialog will be used when --secondary-ui-md is enabled.

(With that flag) The dialog also becomes window-modal on Mac, rather
than tab-modal. This is consistent with other platforms. That's the easy
bit -- ProfileSigninConfirmationDialogViews::ShowDialog() "Just Works".

Adds a browser_test for showing the views dialog - it had no prior
coverage. Uses the fix in r447216 to detect these "transient" child
windows.

Also, there was a memory leak.
OneClickSigninSyncStarter::OnRegisteredForPolicy() allocated a
SigninDialogDelegate with `new` which was never released. Cocoa tests in
profile_signin_confirmation_view_controller_browsertest.mm didn't pick
this up because the tests use the test harness as the delegate (passing
`this`). The right fix is to pass a std::unique_ptr - do that.

BUG=681049 Review-Url: https://codereview.chromium.org/2625813003

Review-Url: https://codereview.chromium.org/2667773003
Cr-Commit-Position: refs/heads/master@{#449485}
Committed:
https://chromium.googlesource.com/chromium/src/+/3d35b33c364f4a5b8872b96b73df...
==========

[commit-bot: I haz the power, 2017-02-10 00:18:08]

Committed patchset #4 (id:60001) as
https://chromium.googlesource.com/chromium/src/+/3d35b33c364f4a5b8872b96b73df...