Manual bisect:
Good build: 53.0.2776.0 
Bad build: 53.0.2777.0 

Note: 1) Above issue is not reproducible on Chromium builds, hence providing suspect from Changelog URL.
2) Issue is reproducible on Windows 8, Mac (10.10.5, 10.11.4) and is not seen on Linux OS (14.04 LTS).

Changelog URL:
https://chromium.googlesource.com/chromium/src/+log/53.0.2776.0..53.0.2777.0?pretty=fuller&n=1000

Suspecting: r401469 ?

Deleted: firstrun_actual.mp4 868 KB

	firstrun_actual.mp4 868 KB View Download

Deleted: firstrun_expected.mp4 449 KB

	firstrun_expected.mp4 449 KB View Download

Adding RB Label as this is a recent Regression. Please remove if not required.
Thank You.

Is there a way to get a narrower bisect range for this?

I'm pretty sure it's not my CL (my code doesn't run on Mac), but I looked through the revision list and I don't see an easy suspect.

Does it repro on the next build of 53?

Thanks.

Er, the next build of 54?

Oh, it's been broken since June 22nd. Never mind about the next build of 53/54.

tommycli@ - could this be due to this CL? It's the only thing I see in the blame list that would touch both Win and Mac and possibly be related to startup. If not it's gotta be something like one of the WeakPtr or MessageLoop CLs. :-(

Clean up LoginUIService. Remove Singleton behavior from PeopleHandler

The old SyncSetupHandler used in Old Options should retain its Singleton behavior.

BUG=563721
Committed: https://crrev.com/86fed6eaf1ec5922b03282b0e99d91c5b87ea1da
Cr-Commit-Position: refs/heads/master@{#401357}

Yeah, I double-checked and my code doesn't run on Windows either, just Chrome OS.

tommycli@ -  Since this issue is marked as RB-Stable will you mind checking it as per comment #5? 
If it's not related to your change please feel free to reassign it to the concerned Dev person .

Thanks!

I will check it. Sorry for the delay.

I ran a git bisect, and the culprit is https://codereview.chromium.org/2054773002.

This can be reproduced with Chromium Linux if you put the following in the  out/rel/master_preferences file (or wherever your build directory is):

{
  "distribution": { 
    "skip_first_run_ui": false
  }, 
  "first_run_tabs": [ 
    "http://welcome_page",
    "http://new_tab_page"
  ] 
}

Also, when verifying this bug, you must wait for the Welcome tab to finish loading. If you click "New Tab" before the Welcome tab finishes, the bug does not manifest.

The fix will need to be merged to 53.

Most probably this is due to this bug  crbug.com/627522 

According to this
https://cs.chromium.org/chromium/src/chrome/browser/first_run/first_run.cc?sq=package:chromium&dr=C&rcl=1468567049&l=436
The first run bubble is suppressed if a global error bubble is pending.

A fix for  crbug.com/627522  has landed.

I will test it in the next Canary build on a Mac.

I tested Canary version 54.0.2799.0 on Mac 10.11.5, and the issue is fixed there.
The bubble showed as expected.