New issue
Advanced search Search tips

Issue 807203 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Feb 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

--user-data-dir on comand line not respected for users with roaming profiles

Reported by johan.mo...@rapunzel.com, Jan 30 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36

Steps to reproduce the problem:
1. Setup windows 10 user with roaming profile
2. start a chrome session
3. from the windows comand line run chrome.exe --user-data-dir="some-new-directory"

What is the expected behavior?
Expected behaviour is a new chrome session that does not share state with the original window

What went wrong?
All the settings from the original sessions are still in efect and it is possible tom move tabs between the windows

Did this work before? Yes Unsure about exact version, but this was working on latest chrome in spring 2017

Chrome version: 64.0.3282.119  Channel: stable
OS Version: 10.0
Flash Version: 

The intended use case is to run different chrome sessions with different proxy settings. We are also using different themes to keep track of which window are using which proxy
 
Cc: kkaluri@chromium.org
Labels: Needs-Triage-M64
Kiran, can you please take a look?
Labels: Needs-Feedback
Tested this issue with chrome #64.0.3282.119

Steps followed :
1. Logged into Windows 10 machine and launched the chrome from desktop by double clicking on it.
2. Observed the bookmark bar and chrome settings are synced
3. Close the browser.
4. Launch the chrome with --user-data-dir argumeents

Observations:
On launching chrome observed the same bookmark bar and chrome settings, that were seen in step 2

Attaching the screen-cast for reference.

johan.mollevik@ Could you confirm that this issue you are facing ???
807203-M64.mp4
3.0 MB View Download
It looks like the issue I have encountered. The test procedure is not the exact same I used but I think it shows the same problem.
Project Member

Comment 4 by sheriffbot@chromium.org, Jan 31 2018

Labels: -Needs-Feedback
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
Cc: pastarmovj@chromium.org
Labels: Enterprise-Triaged
Status: Untriaged (was: Unconfirmed)
Tested this issue with chrome #60.0.3112.90 as steps mentioned in comment #2 and observed the same behaviour, this is a non-regression issue hence marking it as untriaged.

Attaching the screen-cast for reference.
807203-M60.mp4
2.4 MB View Download
Question to both the reporter as well as Kiran:

Do you have any policies in effect? If so which ones? 

The video from Comment 7 clearly shows that chrome is storing the User Data in the specified location and it seems like the RoamingProfileSupportEnabled policy is in effect and syncing the two profile locations.

Hi Julian, above issue was tested in "Local Sync Test Environment-Regression Test" environment where RoamingProfileSupportEnabled policy is in effect.
Labels: Needs-Feedback
Then the feature is working as intended and syncing between the local profiles. Since it is applied as a system wide policy it is effective in all instances regardless of their location. If you try this without the roaming profile feature turned on you will not observe the profiles getting synced.

I assume this is the case for the original reporter as well but I would like to get the feedback there as well to avoid wrongly triaging the situation.
johan.mollevik@ Could you please respond to the comment #8,#10
Hi

I just redid my original test.

The difference in test method from what I can see in the videos in #2 and #7 closes down the first window before opening the second profile, if I do that I can also observ that the profile path changes in chrome://version
What I originally reported was that when leaving the first window open the profile path did not take efect.

Attachign screenshot
Skärmklipp.PNG
84.5 KB View Download
Re #12: But you have no policies otherwise?

Without anything overriding it --user-data-dir should be applied regardless of the fact that other windows are opened and if it doesn't this is a bug.
Yes, I could not find any chrome related policied being in effect. We had one that we disabled to get it working in the first place a year ago but now no chrome replated policies should exist.

On that note, is there any way from within chrome to report what policies it picks up in case chrome and the windows admin tools does not agree on that?

Yes, this is in my opinion a bug.
Yes, newer (as in 63+) versions of chrome provide the "Export" button which will store a JSON file with all policies as loaded by the browser which you can use to attach to bugs or analyze internally.
I have done som further testing and thing that this bug can be closed as not a chrome bug.

The issue was, when looking in the windows policy managment tools we saw no policys affecting chrome. However when typing chrome://policy/ in the address bar we did.

This is most likelly caused by bad caching behaviour on the windows side. Running gpupdate and rebooting some machines cleared the issue.

Thanks for your help and quick response time. If anyone comes across this with a similar issue my tipp is to check chrome://policy/ rather that just trusting what windows reports.
Status: WontFix (was: Untriaged)
Thanks for the feedback!

Sign in to add a comment