Reviewing.... 

There are three issues here:

(1) Enterprise user wants to block Welcome page.

(2) Welcome page should not be shown to users who cannot sign in.

(3) Welcome page shows on every launch after reboot.

For (1), we know of this need and are having discussions elsewhere about how to resolve it.

For (2), obviously the desired case is that we don't show it period and we intend to fix that. But in the interim, tom.case@, can you elaborate on what happens if you actually click on the Sign In button?

For (3), I suspect that the issue here is not related to policy or our promo specifically, but to the App Restore feature present on Mac OS. I've been able to repro that our Welcome page (and any other open tabs) will be present on subsequent launches if (and only if) Chrome is running when Mac OS is restarted. tom.case@, can you check 
  (a) whether the page appears if you close Chrome prior to restarting your computer, and
  (b) whether the page appears if you navigate away from the Welcome page prior to restarting your computer?

Whoops, "close Chrome" should read "quit Chrome" in (3)(a) of comment #5.

And one more followup question: are you seeing the chrome://welcome page on *first* run of Chrome, or on *second* run? Can you please specify what you've set for session.startup_urls and first_run_tabs in your master_preferences file?

Hi tmartino@, in answer to your questions:

(2) - the Chrome sign in dialog appears, but upon entering login details, the account doesn't actually appear to be signed in anywhere (no error messages) so it appears sign in is still actually disabled.

(3)
(a) The welcome page definitely does reappear after restart if Chrome is quit gracefully before restarting.
(b) Have tried closing tab, opening a new tab, browsing to a website, quitting Chrome gracefully and restarting the machine and the welcome page is still present afterwards.

In response to ew...@ - it's always on a first run after a restart. Quitting Chrome and reopening in the same session does not make the welcome page reappear. I'm not using a master_preferences file as far as I know, just the property list posted in my initial post which is being deployed via Profile Manager.

Hmm, that's interesting. Thanks for following up.

The design of this Welcome page is to show it once per Chrome profile. Is it possible that your configuration creates a new profile, or writes over/deletes part or all of the existing profile (~/Library/Application Support/Google/Chrome/Default), on Mac Login?

Enterprise suggested I +cc a Mac TL who might have some insight into how the plist and Policy Manager would be interacting with preferences.

Could you please take a screenshot of each step of the sign-in flow?

And after going through the sign-in flow, could you also go to chrome://md-settings and chrome://signin-internals and take a screenshot of what's shown on both of those pages?
 

replacing me with shrike@ for Mac feedback. 

Hi all, thank you again for the responses about this.

@tmartino: Yes, spot on, the accounts have network home folders with ~/Library/Caches and ~/Library/Application Support redirected to the local disk and cleared on logout.

@ew...: Requested screenshots are attached. As demonstrated by Step 4, the sign in isn't processed, and just puts the user back on the same chrome://welcome page

Deleted: Step 1.png 109 KB

	Step 1.png 109 KB View Download

Deleted: Step 2.png 99 KB

	Step 2.png 99 KB View Download

Deleted: Step 3.png 80.8 KB

	Step 3.png 80.8 KB View Download

Deleted: Step 4.png 112 KB

	Step 4.png 112 KB View Download

Deleted: md-settings1.png 104 KB

	md-settings1.png 104 KB View Download

Deleted: md-settings2.png 114 KB

	md-settings2.png 114 KB View Download

Deleted: md-settings3.png 110 KB

	md-settings3.png 110 KB View Download

Deleted: md-settings4.png 86.2 KB

	md-settings4.png 86.2 KB View Download

Deleted: signin-internals.png 90.2 KB

	signin-internals.png 90.2 KB View Download

Interesting okay, thanks for the info. I think there are two separate things going on here:

1) When you try signing in with an account for which sync has been disabled by admin policy, I believe we're supposed to show a modal error dialogue.

+Mihai - can you please double check this? In this scenario, a user is trying to sign in with an enterprise account that has had sign-in disabled by policy. IIRC we have an error dialogue for that. Any idea why it's not triggering?

2) We show the chrome://welcome page by default for every new profile. However, we used to show chrome://chrome-signin by default on every new profile as well. So if I understand correctly, the only thing that should've changed for you between 56 and 57 is that chrome://welcome is getting shown instead of chrome://chrome-signin. Can you confirm whether on 56, users say chrome://chrome-signin by default on every restart?

Nope, this is the first time I've had a page like this appear since I've been managing Chrome in this way! I've never had chrome://chrome-signin appear on previous versions, only the start page defined in the com.google.Chrome.plist I attached in the first post, very strange!

OK, got it. In that case, this sounds like a regression we need to address.

Tommy - can you please investigate this? You can focus on why we're showing chrome://welcome each startup (and what has changed about that logic); Mihai can take a look at why the signin error dialogue isn't being shown.

The old page had logic to prevent display when sign-in is disabled. If the user hadn't set that policy, then he likely would have seen chrome://chrome-signin on each restart.

We just discovered this issue in our company as well.  Some minor differences in our situation:
OS: Windows not Mac
Ver: 57.0.2987.110
Worked before in: 56.0.2924.87

We do not use master_preferences for anything just GPO ADMX files.  I believe what kept the welcome screen away previously is the GPO setting "Google Chrome - Default Settings (users can override) > Startup pages > Action on startup set to Enabled with the setting of Open a list of URLs along with URLs to open on startup being enabled with our list of URLs to open listed".  The Chrome://Welcome is only showing for users that had not previously launched Chrome before the update to 57.0.2987.110.  In our case if the user launches and closes Chrome the welcome screen does not return as other users have reported.

What I've tried and didn't work:
Via the GPO enabling the Disable synchronization of data with Google
Pre-seeding a user's windows profile with the file "First Run" in the appdata\local\google\chrome folder
Modifying the master_preferences file with "Show_Welcome_Page":false

Please let me know if you need any additional information.

I expected this to be the case, but just to show that I've tested it, the issue is still there in 57.0.2987.133

A friendly reminder that M58 Stable launch is coming soon! Your bug is labelled as Stable ReleaseBlock, please make sure to land the fix, verified in trunk and get it merged into the release branch ASAP.

A friendly reminder that M58 Stable is launch is coming soon (less than 2 weeks)! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you!

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

commit cab3dfe03ca689d5eb085e7a06418e22cbf31a42
Author: tmartino <tmartino@chromium.org>
Date: Thu Apr 06 21:52:31 2017

[Desktop FRE] Do not show Welcome if sign-in disabled

BUG= 702576 

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

[modify] https://crrev.com/cab3dfe03ca689d5eb085e7a06418e22cbf31a42/chrome/browser/ui/startup/startup_tab_provider.cc
[modify] https://crrev.com/cab3dfe03ca689d5eb085e7a06418e22cbf31a42/chrome/browser/ui/startup/startup_tab_provider.h
[modify] https://crrev.com/cab3dfe03ca689d5eb085e7a06418e22cbf31a42/chrome/browser/ui/startup/startup_tab_provider_unittest.cc

Verified in today's Canary.

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

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

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

commit 0c5c1e36cde0084f2be1ef0bc68dd89cd621b3cc
Author: Tommy Martino <tmartino@chromium.org>
Date: Mon Apr 10 21:36:11 2017

[Desktop FRE] Do not show Welcome if sign-in disabled

BUG= 702576 

Review-Url: https://codereview.chromium.org/2786883008
Cr-Commit-Position: refs/heads/master@{#462636}
(cherry picked from commit cab3dfe03ca689d5eb085e7a06418e22cbf31a42)

Review-Url: https://codereview.chromium.org/2810873003 .
Cr-Commit-Position: refs/branch-heads/3029@{#655}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/0c5c1e36cde0084f2be1ef0bc68dd89cd621b3cc/chrome/browser/ui/startup/startup_tab_provider.cc
[modify] https://crrev.com/0c5c1e36cde0084f2be1ef0bc68dd89cd621b3cc/chrome/browser/ui/startup/startup_tab_provider.h
[modify] https://crrev.com/0c5c1e36cde0084f2be1ef0bc68dd89cd621b3cc/chrome/browser/ui/startup/startup_tab_provider_unittest.cc

Hi all

I've tested 58.0.3029.81 this morning and am happy to report this issue is successfully resolved. Thank you very much to everyone who worked to get this fixed.

Cheers

Hi

Sorry guys this appears to have come back in version 60. windows, mandatory profiles, google profile is not saved, happens on every login 1st run.

Giles.

Hi Giles,

We recently turned the new Welcome page on for a broader audience. However, that doesn't mean it should be showing up under all circumstances. Could you provide some more information?

1. What specific steps are you taking that are meant to block the promo from appearing?

2. Could you go into more detail about how you're using mandatory profiles?

3. I'm not sure I understand what "google profile is not saved" means in this context.

4. Could you please copy and paste the contents of chrome://version (with any PII, such as usernames in the file paths, redacted)?

Thanks!

I am glad I found this thread.  It is recent and relevant.   My organization is having this problem as well.  It was found as we just reimaged a computer lab.  Win 10.

New poster answering question 34.

1.  Group Policy from Active Directory Domain.  Enable showing the welcome page on the first browser launch following OS upgrade.  Setting:  Disabled

2.  I'm not using roaming profiles at all.

3.  I'm not what the poster means either.

4.  chrome://version

Google Chrome
61.0.3163.100 (Official Build) (64-bit) (cohort: Stable)
Revision
57c9d07b416b5a2ea23d28247300e4af36329bdc-refs/branch-heads/3163@{#1250}
OS
Windows
JavaScript
V8 6.1.534.41
Flash
27.0.0.130 C:\Users\x\AppData\Local\Google\Chrome\User Data\PepperFlash\27.0.0.130\pepflashplayer.dll
User Agent
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36
Command Line
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --flag-switches-begin --flag-switches-end
Executable Path
C:\Program Files (x86)\Google\Chrome\Application\chrome.exe
Profile Path
C:\Users\x\AppData\Local\Google\Chrome\User Data\Default
Compiler
MSVC 2015 (PGO)
 

We want to use Chrome on our 1.000+ devices in our company. But theres a big showstopper.

It is not possible to suppress the chrome://welcome-Page on first run - even the login to chrome is blocked via GPO. The users are not allowed to login with google accounts to sync their data. We use RoamingProfiles (pb-file) to sync Chrome settings to our Home-Directory.
So the welcome page is confusing for the users - they will call our support to ask why they have to login to google if its blocked.
Please - we need the possiblity to suppress the Welcome-dialog via GPO.

master_preferences:
"show_welcome_page": false,
"suppress_first_run_bubble": true
didnt work.

Google Chrome	62.0.3202.94 (Offizieller Build) (64-Bit) 
Überarbeitung	4fd852a98d66564c88736c017b0a0b0478e885ad-refs/branch-heads/3202@{#789}
Betriebssystem	Windows
JavaScript	V8 6.2.414.42
Flash	27.0.0.187 C:\Users\d73357\AppData\Local\Google\Chrome\User Data\PepperFlash\27.0.0.187\pepflashplayer.dll
User-Agent	Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Compiler	MSVC 2015 (PGO)

Hi,

you can achieve this with the RestoreOnStartup and RestoreOnStartupURLs set as recommended policies after Chrome reaches v64. Some recent changes (https://bugs.chromium.org/p/chromium/issues/detail?id=756545#c27) made it possible to set a specific set of predefined tabs with those two policies and they will be used on furst run and any other run for that matter until the user decides to set this setting himself. It won't alter the behavior for existing users that have modified the default preference themselves.

Hi,

thanks for you fast reply. We already set this to our intranet page. But on the first run, it still opens the chrome://welcome page beside our predefined tabs.

Have you tried this with Chrome from the dev (or maybe by now even beta) channel? Chrome Stable has not reached version 64 yet.

I tried it with

Google Chrome	64.0.3278.0 (Offizieller Build) dev (64-Bit) (cohort: Dev)
Überarbeitung	6218872807f9d8f9e64630c7cefe0ab18954585a-refs/heads/master@{#519169}

1.) First start chrome after installing
 => First Tab: chrome://welcome
 => Second Tab: Predefined intranet-page
2.) Close Chrome
3.) Second start
 => Predefined intranet-page tab only

GPO:
URL-List (with intranet-page) is set.
Re-open last used tabs is disabled.

Sorry it seems this build just barely missed the change that is needed. It will be in from 64.0.3280.0 onwards. You can take the current canary which already is way ahead of this build.

It works! Thank you!

Google Chrome	65.0.3286.2 (Offizieller Build) canary (64-Bit) (cohort: 64-Bit)
Überarbeitung	49ce0f38b07eb28952126b947fa395daf1455d02-refs/branch-heads/3286@{#2}