pawlus.patrick@ For better understanding of this issue Could you please help us with the screen-cast of this issue.

Thank You...

1. First Start: Works as expected
2. Second Start: -"-
3. Recommended Policies are set
4. Change "RestoreOnStartup" Settings in Chrome
5. Third Start: Welcome Page Shown

If something is not clear or need additional informations don't hesitate to ask.

Thanks!

Deleted: 2018-03-21_13-00-08.mov 2.8 MB

	2018-03-21_13-00-08.mov 2.8 MB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

pawlus.patrick@ Could you confirm whether this Win 7 machine is a standalone or connected to some Active directory ?

This is an App-V sequencing machine. It's connected to AD but no policies are assigned.

All settings are set only per master_preference or registry.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Julian@ Could you please help us in triaging this issue further...

Thank You...

Greg, can you take a look at that. 

It seems that when the policy is set as recommended and the user overrides it we fall off of the managed case and all welcome annoyances are back. Do we want to support this case through master prefs or set this pref on first run when the policy is set (recommended or mandatory).

+tmartino

Setting has_seen_welcome_page via master_preferences is not supported, and has probably never worked due to the way the pref works. I don't think we should add more complexity to master_preferences for this case.

Does it make sense to broaden the thing that are_startup_urls_managed is trying to accomplish so that it is true even if the user has set their own startup tabs pref over a recommended policy setting? Alternatively, do we need a new policy setting to suppress promos/welcomes/onboarding/etc?

+1 to grt's comments; this is not a good way to suppress the Welcome page.

IMO the connection between startup URLs and promos has caused a lot of confusion and led to lots of misdiagnosed bugs. I get the argument that it's supposed to mean "show exactly this set of content" and that therefore you can implicitly disable promos by virtue of excluding them from that set of content.

But I don't think it's the most direct expression of what the various reporters on this topic are trying to accomplish here, and it sounds like broadening it would also add undesirable complexity. Even as a dev (let alone an admin) I would find it very hard to intuit why setting are_startup_urls_managed would have any impact on what's shown once the user changes their startup URLs.

My preference would be a single policy setting that would explicitly suppress this type of content.

+georgesak who I know has considered implementing something like that in the past.

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

commit 117b5f5af29baad887eb25d77d1f5fd819152533
Author: Greg Thompson <grt@chromium.org>
Date: Thu Jun 14 20:47:40 2018

Broaden implicit suppression of welcome pages.

Also suppress them when the RestoreOnStartup policy has a recommended
value that is overridden with a user-provided value.

BUG= 824059 

Change-Id: I586411b9fded82841e174468cb830604b7121906
Reviewed-on: https://chromium-review.googlesource.com/1100755
Commit-Queue: Greg Thompson <grt@chromium.org>
Reviewed-by: Tommy Martino <tmartino@chromium.org>
Reviewed-by: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#567391}
[modify] https://crrev.com/117b5f5af29baad887eb25d77d1f5fd819152533/chrome/browser/prefs/session_startup_pref.cc
[modify] https://crrev.com/117b5f5af29baad887eb25d77d1f5fd819152533/chrome/browser/prefs/session_startup_pref.h
[modify] https://crrev.com/117b5f5af29baad887eb25d77d1f5fd819152533/chrome/browser/ui/startup/startup_browser_creator_impl.cc

 Issue 873166  has been merged into this issue.