These two dialogs are shown for different purposes.
picture 6 is a profile managed confirm dialog which tells the user his or her profile data will be managed.
picture 7 is a sync confirm dialog which tells the user his or data will be synced to Google.
picture 6 is only for corp account while picture 7 is for everyone.
And if user click undo or cancel, we will undo sign in on purpose. 
The behavior of these two dialogs are mainly because of privacy. I'm not sure if there is any legal reason there.
And ForceBrowserSignin policy doesn't change any behaviors above. The policy only force quit Chrome when user choose undo the sign in.


1) The definition of 'Fresh Profile'. Currently, fresh profile means no extension, no bookmarks, never type url, less than 10 history entries, and never shutodnw(Chrome never close after profile creating). An auto create default profile is not counted as fresh right now which sounds like an issue imo. However, even the fresh profile sign in will still display managed confirm dialog. The only difference is there is no 'Create a new profile' button.

2) Can we provide a policy to let admin change these dialogs into notification. So they can simplify sign in process if they want.

3) For a fresh profile, can we change the manage confirm dialog into a notification.

I can bring this to the sign in and UX team.

--Chrome Identity automated triaging--

This bug is Untriaged and has gone for two weeks without any activity, so it is being moved to Available. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

We always have to display the sync confirmation dialogue, for both privacy and legal purposes (picture 7).

I agree that if it's a "fresh," default profile, we shouldn't have the "Create a new profile" in the managed account confirmation dialogue.

Updating the title of the bug to reflect that. I don't think there's anything else to do here.

--Chrome Identity automated triaging--

This bug is Available and has gone one year without any activity. If another month passes without any activity, this bug will be closed out. Please provide an update with the latest status for this bug. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This is still a valid bug. I'm not sure if anyone on the Enterprise team has time to pick this up; the sign-in team is too busy to triage it currently.

Moving to assigned to make sure that zmin@ sees it.

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Maybe I'll take a stab at this one. If I understand comment 3, the request here is to change the logic in ui::CheckShouldPromptForNewProfile so that it provides false for prompt_for_new_profile when the profile is brand new.

How does one get a browser into the right state so that this dialog will show?

Hi Greg, I was also looking a little into this one.

Just wanted to give you some notes and let you continue since you probably know better:

This dialog is a Sync specific dialog so it seems to only be accessible through the "Turn on Sync" button on the top right, by signing through chrome:://chrome-signin or opening a browser that has a google account signed in but with sync disabled (this one will bring up the Chrome welcome screen with "Web browsing with Google Smarts" where you can click on "Turn on Sync...")

You can get the dialog with the "Create new profile" button if you do the following steps on any fresh user-data-dir:

1. run chrome.exe --user-data-dir=<something that does not exist>
2. goto to chrome://chrome-signin
3. Perform signin with your managed corp account.
4. You will get the mentioned dialog.

However if you do the following steps instead you will get the dialog without the "create new profile":
1. run chrome.exe --user-data-dir=<something that does not exist>
2. Click on the grey user icon on the top right and "Turn on Sync"
3. Sign in with your corp account.

In this situation you will get a dialog with only "Link Data" or "Cancel". There is a caveat to the above repro. If you leave your browser on the NTP long enough two quick links will eventually appear on that page (http:/go and http://goto, most likely downloaded through policy). Once these two links appear the flow mentioned above will also lead to a dialog with the "Create new profile" button. 

For the buggy situations ui::CheckShouldPromptForNewProfile will fail due to:
  helper->CheckHasTypedURLs();
In case #1: because you have obviously typed in "chrome:://chrome-signin" as your url. 
In case #2 where the http://go and http://goto link appear the same thing happens but in the background (likely a buggy association of those links with the PAGE_TRANSITION_TYPED transition type) 

So there may be 2 bugs to fix. 
1. Why is the auto loading of http://go and http://goto associated with a typed transition.
2. Do we want to allow a first typed transition of chrome://chrome-signin to be accepted as a fresh profile? Maybe this case can still be marked as not fresh since the user did in fact type in a url. 

Hope this helps you. 

Deleted: NTP-Go-Goto-Links.png 34.3 KB

	NTP-Go-Goto-Links.png 34.3 KB View Download

Drive-by. I'm not understanding all the details here, but please note that chrome://chrome-signin is deprecated. It's probably not worth making any changes in that flow. To my knowledge this is only used in very small edge cases (such as the force signin policy) and we want to remove it completely.

chrome://welcome is the new FRE/welcome page experience that we use instead of chrome://chrome-signin. 

Thanks for the info, droger. The issue is with the "Link your Chrome data to this account?" dialog. If that dialog will continue to be used in the force signin case, then we'd like to fix this. Will it, or is that dialog also going away?

tienmai: thanks for all of the details. I'm happy to continue with this, though I'm not sure I know any better than you. :-) Feel free to run with it if you wish.

Yes the dialog is also shown as part of the new flow, and the code for the dialog is shared.
However the code that triggers the dialog is not shared.

Basically the deprecated code is here:
https://cs.chromium.org/chromium/src/chrome/browser/ui/sync/one_click_signin_sync_starter.cc?rcl=b94e1fd68e12827ed018ab5b41fbe32251df5a0a&l=237

The new code is here:
https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/signin/dice_turn_sync_on_helper.cc?rcl=b94e1fd68e12827ed018ab5b41fbe32251df5a0a&l=244

I don't think you need to fix the deprecated code, we're planning to remove it.

I've tried to repo the bug as-described using the BrowserSignin=force policy setting, and I don't see account linking dialog at all (launch with fresh user data dir, sign in, see a browser, accept the sync dialog). Should I?