Issue metadata
Sign in to add a comment
|
Extensions lost when Chrome exits
Reported by
ctd1...@gmail.com,
Jan 29 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. Start Chrome (do not log in) 2. Install extension 3. Exit Chrome 4. Restart Chrome What is the expected behavior? The extension should still be installed/configured. What went wrong? The extension is no longer installed. We have tested this with multiple extensions and have seen the same behavior, so I don't think it has anything to do with our extension specifically. This started happening with Chrome 64 and I have verified that it is still happening with Canary 66.0.3334.0 64-bit. WebStore page: https://chrome.google.com/webstore/detail/vistaprint-store/cpbljmegemnnmijemdkmaemdgjnjcofe Did this work before? Yes Chrome 63.0.3239.108 Chrome version: 64.0.3282.119 Channel: stable OS Version: 10.0 Flash Version: I had originally thought this might be related to https://bugs.chromium.org/p/chromium/issues/detail?id=795827, but was told that it is a separate issue. The machines this is happening on are public, so users do not log in to Chrome. I've also tried creating a Profile in Chrome, but that also gets deleted when Chrome exits. I've had to downgrade to Chrome 63 until this issue is resolved.
,
Jan 30 2018
,
Jan 30 2018
ctd1685@ Thanks for the issue. Tested this issue on Windows 10 on the latest Canary 66.0.3334.0 and Stable 64.0.3282.119 and unable to reproduce the issue by following the steps mentioned in the original comment. On adding an extension to chrome -> exit and relaunch Chrome -> can observe that the extension is installed after relaunching chrome. No issues are observed. Attached is the screen cast for reference. This issue looks similar to issue 795827 . As per this issue, there was a fix landed on the latest canary 66.0.3334.0. Request you to please retry the issue on the latest Canary 66.0.3334.0 and update the thread with the observations. Thanks..
,
Jan 30 2018
Thank you for looking into this for me! After some more thought and investigation, the behavior we're seeing appears consistent with Ephemeral Profiles mode, but that policy does not appear to be set (according to chrome://policy). I also thought it might be related to issue 795827 and made my initial report there (see Comment 66). pwnall@ in Comment 72 said that my issue was not related, which led me to open this issue. I did test it in Canary 66.0.3334.0 and saw the same behavior. One other data point is that I am not seeing this problem on my own system. It only manifests on the systems I have set up for public use. The main difference I could think of between these systems is that my machine is joined to a domain and the other systems (where we see this behavior) are not. Those machines only have local user accounts. That said, I tried creating a local user account on my box and was still unable to reproduce the problem. At this point, I'm baffled. Please let me know if there is any other information I can provide to help narrow down this issue. Thanks!
,
Jan 30 2018
Thank you for providing more feedback. Adding requester "susanjunia.boorgula@techmahindra.com" 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
ctd1685@ Thanks for the feedback. As per comment #4, as this issue is related to Ephemeral Profiles mode(Enterprise), forwarding this issue to Inhouse team for further help in triaging. kaluri@ Can you please look into this issue and help further? Thanks..
,
Jan 31 2018
Seems like this one is triaged.
,
Feb 2 2018
Some more information: Running Chrome 64.0.3282.140, I tried logging in to Chrome to see if that would persist my Extension settings. It did not, but it did give me a clue by saying that Sync was disabled by the Administrator. This machine is not on a domain and the account I used to log in to Chrome was a newly-created gmail account, so I couldn't see how an Administrator could be involved. Searching for this, I was led to a post that pointed to a Registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\SyncDisabled, which was set to 1. But in that same Registry folder, was a setting called ForceEphemeralProfiles, which was also set to 1. Chrome 63 does not seem to use this setting, at least it does not force ephemeral profiles even though it is set. Chrome 64 does appear to use it, which explains why I suddenly started seeing this behavior after the Chrome 64 update. By setting this value to 0 and restarting Chrome, I got back to the behavior I had been seeing (and relying on) in Chrome 63. Does this seem like a reasonable analysis? Is this an appropriate fix? Is it likely that this will stop working in some future Chrome release? Thank you in advance!
,
Feb 12 2018
ctd1685@ Could you confirm whether did you add chrome.adm template in gpedit.msc ? and also share the screen-shot of chrome://policy for further triage.
,
Feb 12 2018
,
Feb 12 2018
Hi, somehow the ephemeral policy is set for your user (could be admin policy, could be some third party tool writing this key). In either case your analysis is correct up to the point that you should have experienced the same issue in Chrome 63 and the fact that you didn't suggests that this policy was either not set back then or there was some issue with it which luckily is fixed in 64. The whole point of ephemeral profiles is that they wipe themselves (including extensions) every time you close the browser. I think we can close this as working as intended provided there are no further questions?
,
Feb 16 2018
As per comment #11 closing this issue |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, Jan 30 2018