Kiran, can you please try to repro?

Tested this issue on Windows 10 with chrome #58.0.3029.96, #62.0.3202.89

Steps Followed:
1. Modified master_preferences file as per comment #0
2. Deleted chrome folder from location "C:\Users\XXXXXX\AppData\Local\Google"
3. Launched chrome for the 1st time and observed that it navigates to "https://www.google.com"
4. Close the chrome window
5. Again launch the chrome window

Observations:
1. In both M58, M62 builds, on 2nd launch of chrome, it displayed the welcome page.

Attaching the screen-cast for reference.

roarudo@ Could you please look into this issue and let us know your observations, if possible please help us with the screen-cast of your issue.

Thank You...

Deleted: 782684-M58.mp4 1.5 MB

	782684-M58.mp4 1.5 MB View Download

Deleted: 782684-M62.mp4 1.3 MB

	782684-M62.mp4 1.3 MB View Download

Thanks for your try. kkaluri

I guess the behavior is different Windows 10 and Windows 7.
That because Welcome page of 10 is special (chrome://welcome-win10) and not same other's (chrome://welcome).

Attanching the screen-cast.

Hope this helps.

Deleted: 782684-M58-Win7.mp4 657 KB

	782684-M58-Win7.mp4 657 KB View Download

Deleted: 782684-M62-Win7.mp4 824 KB

	782684-M62-Win7.mp4 824 KB View Download

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Able to reproduce this issue on Windows 7 with chrome Stable #62.0.3202.89, Dev #64.0.3260.2

Bisect Info:
===========
Good build : 61.0.3122.0 ,  Revision Range - 477124
Bad build  : 61.0.3123.0 ,  Revision Range - 477506

Note : Unable to run the bisect script, since it involves editing master_preferences file while launching the chrome.

The following CL's between good and bad build versions
===========================================
https://chromium.googlesource.com/chromium/src/+log/61.0.3122.0..61.0.3123.0?pretty=fuller&n=10000


Review-Url: https://codereview.chromium.org/2919223002

isherman@ - Could you please look into this issue, if it's related to your change?  if not could you please help us to reassign this issue to the right owner.

Deleted: 782684-Good.mp4 1.3 MB

	782684-Good.mp4 1.3 MB View Download

Deleted: 782684-Bad.mp4 1.5 MB

	782684-Bad.mp4 1.5 MB View Download

I think this commit is related.
https://chromium.googlesource.com/chromium/src/+/354a45f6ebddc6f449bd1f666d3bce0c7891ef8a%5E%21/

Over to Greg, the author of the commit mentioned in #7, for further triage.  Greg, PTAL – thanks!

Hi Tommy and Patrick. Looks like this is an unintentional result of onboarding tabs being shown outside of first-run; introduced in r439236. For first-run, all is well since tabs provided by GetDistributionFirstRunTabs (the first-run-tabs) lead to suppression of the onboarding tabs. For subsequent runs, though, the onboarding tabs may be shown. Does this sound right?

One possibility would be to add yet another master preference to turn off the onboarding tabs. What do you think of making a blanket suppression of current and future onboarding tabs if distribution first-run tabs are used on first run?

We did consider this concern during implementation, and at that point we decided against a Master Pref for this use case. The thinking in this specific case was that there's probably a strong overlap between people with a good reason to avoid showing the sign-in promo, and people who disable sign-in entirely (n.b., disabling sign-in blocks the promo). That is to say, it's not clear why you would want to allow sign-in, but disallow the Welcome page which kicks off the flow.

That said, I think that our logic here might not sync up to users' expectations and mental models. I know this, and various other issues with new or deprecated or poorly-documented Master Prefs around onboarding content, have generated a decent amount of noise. I'm adding a couple folks from the Enterprise and PM side.

This seems like a dupe of  Issue 703809  to me.

Agreed. Marking as such.

Regarding comment 10, https://bugs.chromium.org/p/chromium/issues/detail?id=787118#c6 provides a different perspective. There are reasonable cases where sign-in is allowed but the promo is not desired.

What do you think about my last proposal above?

I know this is marked as duplicate, but comment 13 seems unresolved.

Are we good with the plan that grt@ outlined?

Whoops, sorry for the delayed response. This must have gotten lost in my inbox over the holidays.

> One possibility would be to add yet another master preference to turn off the onboarding tabs. What do you think of making a blanket suppression of current and future onboarding tabs if distribution first-run tabs are used on first run?

I think a kill-switch (likely a Master Preference) for all onboarding tabs is probably the way to go. It's consistent with the expectations I see on bugs like this where folks are looking for a single bulletproof solution where no promotional content will be shown. It might also be worth doing a bit more research to see if there's an existing Master Pref that "feels like" it should already be doing this, rather than adding a new one.

I *don't* like the idea of using distribution first-run tabs to determine behavior on subsequent runs. The name and function suggest it's safe to ignore this when diagnosing behavior on subsequent runs. The relationship between the trigger and effect isn't obvious enough at face-value, and I can see it creating a lot of confusing code, weird state, and ugly debugs down the line.