Revert of MacViews: Allow the toolkit-views Enterprise Signin Confirmation Dialog to be used

Revert of MacViews: Allow the toolkit-views Enterprise Signin Confirmation Dialog to be used (patchset #7 id:140001 of https://codereview.chromium.org/2625813003/ )

Reason for revert:
The "ProfileSigninConfirmationDialogTest.InvokeDialog_default" test is failing on "Win10 Tests x64" builder.

Original issue's description:
> MacViews: Allow the toolkit-views Enterprise Signin Confirmation Dialog to be used
> 
> 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. This uses the TestBrowserDialog framework, which was using
> GetAllChildWidgets() to detect a dialog being added. This worked on Mac,
> but on Aura the dialog is added as a "transient" child. Update
> TestBrowserDialog to use GetAllOwnedWidgets(), which includes transient
> children as well as other 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
> Cr-Commit-Position: refs/heads/master@{#443751}
> Committed: https://chromium.googlesource.com/chromium/src/+/0dd1562593d3cb4ebe882801d76d747641d7b7f0

TBR=msw@chromium.org,tapted@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=681049
Review-Url: https://codereview.chromium.org/2632123003
Cr-Commit-Position: refs/heads/master@{#443899}
Committed: https://chromium.googlesource.com/chromium/src/+/c6f827f406ef2b71339fa34bc82a632519a84e5b

[pkalinnikov, 2017-01-16 13:45:13]

The CQ bit was checked by pkalinnikov@chromium.org

[pkalinnikov, 2017-01-16 13:45:13]

Created Revert of MacViews: Allow the toolkit-views Enterprise Signin
Confirmation Dialog to be used

[commit-bot: I haz the power, 2017-01-16 13:45:25]

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-01-16 15:34:06]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1484574313309370, "parent_rev":
"ef7bded5e6fb6db4cdef36254e688e12b75eb7bb", "commit_rev":
"c6f827f406ef2b71339fa34bc82a632519a84e5b"}

[commit-bot: I haz the power, 2017-01-16 15:34:33]

Description was changed from

==========
Revert of MacViews: Allow the toolkit-views Enterprise Signin Confirmation
Dialog to be used (patchset #7 id:140001 of
https://codereview.chromium.org/2625813003/ )

Reason for revert:
The "ProfileSigninConfirmationDialogTest.InvokeDialog_default" test is failing
on "Win10 Tests x64" builder.

Original issue's description:
> MacViews: Allow the toolkit-views Enterprise Signin Confirmation Dialog to be
used
> 
> 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. This uses the TestBrowserDialog framework, which was using
> GetAllChildWidgets() to detect a dialog being added. This worked on Mac,
> but on Aura the dialog is added as a "transient" child. Update
> TestBrowserDialog to use GetAllOwnedWidgets(), which includes transient
> children as well as other 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
> Cr-Commit-Position: refs/heads/master@{#443751}
> Committed:
https://chromium.googlesource.com/chromium/src/+/0dd1562593d3cb4ebe882801d76d...

TBR=msw@chromium.org,tapted@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=681049
==========

to

==========
Revert of MacViews: Allow the toolkit-views Enterprise Signin Confirmation
Dialog to be used (patchset #7 id:140001 of
https://codereview.chromium.org/2625813003/ )

Reason for revert:
The "ProfileSigninConfirmationDialogTest.InvokeDialog_default" test is failing
on "Win10 Tests x64" builder.

Original issue's description:
> MacViews: Allow the toolkit-views Enterprise Signin Confirmation Dialog to be
used
> 
> 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. This uses the TestBrowserDialog framework, which was using
> GetAllChildWidgets() to detect a dialog being added. This worked on Mac,
> but on Aura the dialog is added as a "transient" child. Update
> TestBrowserDialog to use GetAllOwnedWidgets(), which includes transient
> children as well as other 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
> Cr-Commit-Position: refs/heads/master@{#443751}
> Committed:
https://chromium.googlesource.com/chromium/src/+/0dd1562593d3cb4ebe882801d76d...

TBR=msw@chromium.org,tapted@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG=681049

Review-Url: https://codereview.chromium.org/2632123003
Cr-Commit-Position: refs/heads/master@{#443899}
Committed:
https://chromium.googlesource.com/chromium/src/+/c6f827f406ef2b71339fa34bc82a...
==========

[commit-bot: I haz the power, 2017-01-16 15:34:33]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/c6f827f406ef2b71339fa34bc82a...