Issue metadata
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 descriptionUserAgent: 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
,
Jan 31 2018
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 ???
,
Jan 31 2018
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.
,
Jan 31 2018
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
,
Jan 31 2018
,
Feb 1 2018
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.
,
Feb 1 2018
Attaching the screen-cast for reference.
,
Feb 1 2018
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.
,
Feb 2 2018
Hi Julian, above issue was tested in "Local Sync Test Environment-Regression Test" environment where RoamingProfileSupportEnabled policy is in effect.
,
Feb 2 2018
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.
,
Feb 5 2018
johan.mollevik@ Could you please respond to the comment #8,#10
,
Feb 12 2018
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
,
Feb 12 2018
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.
,
Feb 12 2018
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.
,
Feb 12 2018
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.
,
Feb 13 2018
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.
,
Feb 13 2018
Thanks for the feedback! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, Jan 30 2018Labels: Needs-Triage-M64