The issue was reproduced in test environment.
- Only the link added in the short cut will be opened 
- Issue will not occur when there is no shortcut command added 
- Issue occurs when the “Manage on startup pages” is set as “Open the New Tab page” or “Open a specific page or set of pages”. 
*When it is set as “Open a specific page or set of pages”, issue occurs and also the specific page added in the settings will not be accessed either. 

hi govind@, could you please help with triage? 

Able to reproduce the issue with below steps :

1. Launch Chrome and visit few sites and pin tabs to tab strip 
2. Exit Chrome
3. relaunch Chrome ""C:\Program Files\Google\Chrome\Application\chrome.exe" --new-window https://mail.google.com/a/vendors.trialdevices.com "



The same works fine with below steps :
1. Launch Chrome and visit few sites and pin tabs to tab strip 
2. navigate to Chrome://settings --> On startup  and set "Open specific page or set of pages" or any other option under it
3. Exit browser and relaunch 


Note : I see similar behavior on Current and previous stable channels i.e., 61.0.3163.91 and 60.0.3112.113, This was working as mentioned in bug report during Chrome version M49 hence marking the bug as regression(not recent one might be a year old)

I'm leaning towards calling this working as intended. When rewriting the logic that determines what tabs are displayed at startup, I intentionally chose to treat command line URLs as specifying *exactly* the set of URLs to be displayed. This allows for creating shortcuts or commands that open a URL without being affected by other browsing state.

There are other, better-supported ways of accomplishing the use case of displaying a tab at each startup while including pinned tabs: for example, adding the desired URL under "Open specific page or set of pages", or (in the enterprise context) setting the corresponding master pref or policy.

Is there a compelling use-case for this which is not adequately served by other configurations?

Also ccing pkasting@ as a heads-up, as he had strong opinions about some of these interactions, and more context on prior decisions, when reviewing the changes I described above.

For me this only happens when I don't have any "unpinned" tabs open. If I close the browser with an "unpinned" tab open, the pinned tabs are persisting between sessions. However, if I close the browser with only "pinned" tabs open, they are removed next session.

Sorry for posting multiple times, but I didn't see an edit button. 

tmartino, I don't think this should be considered "working as intended", as pinned tabs clearly persist between sessions as long as an "unpinned" tab is open when closing the browser. Why would pinned tabs be removed just because an unpinned tab wasn't present?

This issue is reproducible on Windows, Linux and Mac.

Hi there; I wasn't yet able to reproduce any sequence where having non-pinned tabs made a difference in whether or not pinned tabs showed up.

A few questions:
- What is your startup preference? (the value for "On Startup" in chrome://settings)
- Are you launching with a target url (either by command-line argument, or by a shortcut with extra settings attached) like in Comment #1?
- Are you closing the window, or quitting/exiting the application?
- Are there any other steps you can think of that might be necessary to reproduce this?

Thanks!

Answers from my side:

> What is your startup preference? (the value for "On Startup" in chrome://settings)
it is 'Open new Tab Page'

> Are you launching with a target url (either by command-line argument, or by a shortcut with extra settings attached) like in Comment #1?
By a shortcut

> Are you closing the window, or quitting/exiting the application?
Just closing, in regular way

> Are there any other steps you can think of that might be necessary to reproduce this?
Not sure, those steps were enough for me to reproduce. Pinned tab never appears when Chrome launched with that extra setting

 tmartino@
Please let us know if there is any update that can be shared with the customer.

tmartino@
sorry for keep asking, Is there any update for this case?

Hi ryutas@,

Per comment #5 I'm not yet convinced that this is something we should change. Could you follow up and see if there's a really strong reason this couldn't be accomplished by e.g. setting the target page as the startup page in Settings? I find the argument that nothing but the target URL should show fairly compelling, and think there are likely already good workarounds for the situation described.


Re: comments #6-7, I still haven't been able to reproduce this behavior myself. It sounds like an unrelated issue.

tmartino@
Thanks for your comments.

I have also done the quick tests and I could reproduce the same behavior. 
It looks like the behavior has been changed from M60/M61.
Because I could save the pined tabs by M59.
(I have saved M59&M61 behavior results in the below drive site.
https://drive.google.com/drive/folders/0B01YYztUbOCuNFR0RzJsUEdKZU0?usp=sharing)

I will follow up the case and we will create a separate FR if need it.

Able to reproduce the issue on Windows 7 using chrome version 61.0.3163.100 by following the steps mentioned. Below are the bisect details obtained for the same:

Bisect Info:
============
59.0.3071.132 - Good Build (Last build in M59)
60.0.3072.0 - Bad build (First build in M60)

Change Log: https://chromium.googlesource.com/chromium/src/+log/59.0.3071.0..60.0.3072.0?pretty=fuller&n=10000

Unable to narrow down using bisect script as we have to launch chrome for the second time using the flag provided. Not sure how to do this.

Manually searching the change logs, suspecting the below change could be a possible culprit:

https://chromium.googlesource.com/chromium/src/+/2894d3bd6f22f18804bcd6c927a598c662f0547c

@clamy: CC'ing you, request you to please check and confirm if this is caused by your change.

Thanks.!

@ranjitkan: I don't think this is related to my change. It only touched the CaptivePortalTabHelper which is a class used to detect whether a captive portal is present which does not seem related to the issue at hand. Also, there was no functionality change, it was done to avoid a uaf bug.

Hey folks--I understand why the behavior described in c#1 is happening in the code; there's no need to attempt a repro or a bisect. The issue is a question of what the desired behavior is.

The issue in c#6 is separate, and doesn't seem to repro for me. I'm happy to look into it if we can get more instructions.

Closing as WAI. Per c#13, we can revisit as a FR if we have more info from the user in question.