Able to reproduce this issue on Windows 10, Ubuntu 14.04 and Mac 10.12.3 with chrome #59.0.3030.0

Bisect Info:
==============
Good Build : 58.0.3029.3
Bad Build  : 59.0.3030.0

Unable to run bisect script, since it giving all bad builds while executing the script.

CL's between good and bad builds
===================================
https://chromium.googlesource.com/chromium/src/+log/58.0.3029.0..59.0.3030.0?pretty=fuller&n=10000


The possible culprit CL's for this issue 

https://chromium.googlesource.com/chromium/src/+/6a8242fa680b56f7052e1233e9472bf00ed1e27b

https://chromium.googlesource.com/chromium/src/+/85e97545954dc8828c9e76c1ba3ead10e9a6007e

CC'ing the concern owners

alito@, gonzalon@ 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.


Thank You...

For above issue i have executed per-revision bisect script.

My CL is unrelated and cannot be the cause of the bug (that code path is not run unless a feature flag specifically enables it).

Again Bisected with the range 

Good Build : 58.0.3028.0, Revision Range - 454140
Bad Build  : 59.0.3030.0, Revision Range - 454724

Executed the per-revision bisect script on Win10, Ubuntu 14.04 and mac 10.12.2 for the above range

In Windows 10, per-revision bisect script has given irrelevant CL

https://chromium.googlesource.com/chromium/src/+log/6581fa97d9ac35a9c541856a0acc04c8be2cfc20..7503282e3514c85f13effc533f9b3cc1c4b5dc8d

In Ubuntu, per-revision bisect script has given all bad Builds while executing

In Mac, per-revision bisect script not invoking the chrome builds while executing

On manually looking into CL between good and bad,suspecting the below CL for this issue.
https://codereview.chromium.org/2725813003

CC'ing the owner of this CL

I would be very surprised if my change, which was isolated to tests, caused this issue. 

Issue appears resolved in Canary 59.0.3036.0 on Windows 10x64.

Thanks for the observant cc, pkasting. This is related to my changes awhile ago.

Last fall I rewrote the startup code responsible for determining the content opened at launch. As part of that process, I discovered that this behavior (deduplication of pinned tabs appearing in preferences) was already very buggy and would not trigger in many common use cases. After investigating trying to fix it, I decided for a variety of reasons that it was best to just rip this out. I've got fairly extensive notes on why I made that decision if anyone is concerned and would like to read more.

Going forward the expectation is that pinned tabs and startup preference tabs are completely independent of one another. Any tabs that are pinned when closing Chrome will reappear as pinned tabs at the next launch, and any tabs that are selected in preferences will surface as full tabs on each new instance of Chrome.

Note that this has not been fully turned on on Windows yet, so the old flaky behavior may still sometimes be observed on that platform, especially on Windows 10.

For now I'm closing as WAI, but feel free to follow up with concerns.