This definitely seems worth addressing. Marking as assigned.

Also, this happened more often with force-sign-in. With force-sign-in, the sign in process will be finished without browser window completely. And once it's done, the browser window will be opened and the sync confirm window will always be shown together with the ntp loading. 

What're more, with force-sign-in, all browser window needs to be closed during the sign out. While this issue will trigger the sign out event when the sync confirm dialog is dismissed by itself.


For more information about force-sign-in (Googler only):
https://docs.google.com/a/google.com/document/d/1cfDuV6n7puoWV2cMVI_LXlY8TOh1_jNulVPHyGjXW94/edit?usp=sharing

I cannot reproduce this (I've tried on ToT on Mac). I have done the followinh:
* added the following piece of code on start-up:
    chrome::NavigateParams* lateParams =
        new chrome::NavigateParams(browser, GURL("http://www.google.com"),
                                   ui::PAGE_TRANSITION_AUTO_TOPLEVEL);
    base::ThreadTaskRunnerHandle::Get()->PostDelayedTask(
        FROM_HERE,
        base::Bind(&chrome::Navigate, lateParams),
        base::TimeDelta::FromMilliseconds(10000));


This basically loads the Google webpage in the current tab after 10 seconds. I've started Chrome and then I opened the modal sign-in view. When the navigation happens, the sign-in is not dismissed.

Note that with the sign-in dialog on-screen or with the sync confirmation dialog on screen, I can use the navigation buttons (back & forward) and the dialog is not dismissed then either.

I think I would need a more precise repro case (something with steps and username/password I could use).

Re-assigning to zmin@ for a repro case. Please re-assign to me once you have added the repro case.

Thanks msarda@

There is another way to trigger this issue. And because it happened much more often, I actually have added a workaround hack.

1) Remove the hack here from line 486 to line 487.
https://cs.chromium.org/chromium/src/chrome/browser/ui/sync/one_click_signin_sync_starter.cc?q=one_click_signin_sync_starter.cc&sq=package:chromium&dr&l=485
2) Sign in with any corp account (i.e. google account).
3) In dialog "Link your chrome data to this account", choose "Create a new profile".
4) The Sync confirmation window will be shown and dismissed in the new window.

I managed to reproduce this (thanks for the pointers). My understanding is that  it is Chrome's intent to close all WebUI dialogs on a main frame navigation:https://cs.chromium.org/chromium/src/components/web_modal/web_contents_modal_dialog_manager.cc?rcl=0&l=147

I think this makes the assumption that all WebUI dialogs are related to tab's URL, so it makes sense to close them when the page navigates.

The sync dialog is not attached to the tab, so it does not make sense to close when when the page navigates. I need to see how this can be implemented.

Issue 666910 has been merged into this issue.

The decision was to use browser modal dialogs (instead of webcontents modal dialogs). As explained in the CL, there is not difference in the presentation of the sign-in dialogs, but rather in their behavior:
* the browser modal dialogs has the focus and the user cannot interact with the browser window before the modal dialog is dismissed.
* the browser modal dialogs are not dismissed tab navigation

Screenshots:
https://drive.google.com/open?id=0Bw1MJ8m7U5kbSHdYZ0lsdlJ2bW8
https://drive.google.com/open?id=0Bw1MJ8m7U5kbU2dOTzZGVjR1U1U

Your screenshots are not accessible to any account I have.  Please make them world-viewable?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/4d89528f55ebdfe107f61592694272af8b362a55

commit 4d89528f55ebdfe107f61592694272af8b362a55
Author: msarda <msarda@chromium.org>
Date: Thu Dec 22 21:25:48 2016

Change sign-in dialogs to be browser modal.

The sign-in modal dialogs (sign-in dialog, sync confirmation dialog,
sign-in error dialog) have a lifecycle that is independent of the current
web contents. This CL changes them to be presented as browser modal dialogs
(and not web-contents modal dialogs).

There is not difference in the presentation of the sign-in dialogs,
but rather in their behavior:
* the browser modal dialogs has the focus and the user cannot interact with
the browser window before the modal dialog is dismissed.
* the browser modal dialogs are not dismissed tab navigation

Screenshots:
https://drive.google.com/open?id=0Bw1MJ8m7U5kbSHdYZ0lsdlJ2bW8
https://drive.google.com/open?id=0Bw1MJ8m7U5kbU2dOTzZGVjR1U1U

BUG= 663751 

Review-Url: https://codereview.chromium.org/2594353002
Cr-Commit-Position: refs/heads/master@{#440506}

[modify] https://crrev.com/4d89528f55ebdfe107f61592694272af8b362a55/chrome/browser/ui/views/profiles/signin_view_controller_delegate_views.cc

Note that the CL above only fixed the bug on views framework (Linux and Windows), not on macOS. The macOS needs to be fixed as well.

Should we re-open this bug to keep track of the Mac work as well, then? Also, do we need to merge this to 56 for any particular reason Mihai?

Nevermind re: keeping this one open. Saw that you already opened  Issue 677012 .

++Observation:
Steps:
1)Launch chrome and open any page 
2)Resize the window to minimum extent and open sign in overlay page
3)Now,Try to maximise/minimise/close browser window and Observe.

Actual:Unable to any operations when sign in dialog is present.

@msarda: Please confirm whether it is an intended behaviour or an issue.

We are using a standard browser window modal dialog and it appears this is the behavior of the window when such a dialog is presented (it is the same behavior as for the case when the user attempts to save a page or to add it to desktop). 

So yes, this is the expected behavior.