Installation date for Chrome not being updated in Registry
Reported by
alton...@gmail.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. Install Chrome (note the date of installation) 2. Configure and allow Chrome to auto-update at a later date 3. Open appwiz.cpl and check the installation date, you'll notice it was the original installation date and is not updated to reflect the installation date of the new version. What is the expected behavior? When other software updates, the InstallDate Field in the Uninstall Keys (listed below) are updated to reflect the date of the latest update. Whilst the "Version" key is being updated, this mismatch causes confusion, for example on my machine I have 64.0.3282.119 listed as being installed back in 2015. It could be expected that the InstallDate is updated to reflect the installation of the most update. Relevant registry keys: - Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome\InstallDate OR - Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome\InstallDate) What went wrong? The below registry keys are not being updated with the new installation date. Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome\InstallDate (or WOW6432Node equivalent) Did this work before? No Chrome version: 64.0.3282.119 Channel: stable OS Version: 10.0 Flash Version: Obviously, this is low priority and there's probably no specific recommendation from Microsoft on whether the InstallDate value should or shouldn't be updated. If you won't update the InstallDate to the date of the installation, would you consider removing the InstallDate field altogether, as it appears Windows then looks at the date the registry key was updated when listing applications in the "Programs and Features" control panel menu?
,
Jan 31 2018
,
Jan 31 2018
The current behavior is by-design: InstallDate is the date on which Chrome was installed. I am hesitant to change this, as I would not be surprised to find that there are enterprise administrators who depend on this. What is it that you're trying to accomplish? Perhaps there's another way.
,
Jan 31 2018
altonius@ Thanks for the issue. Adding TE-NeedsTriageFromHYD label and routing this issue to Installers team for further help in triaging this issue. grt@ As per comment #3, can you please confirm if bisect is required for this issue or not? Thanks..
,
Jan 31 2018
grt@ In summary, I'm trying to check which of my apps are being updated by sorting them by the install date (using either the "Installed On" column in appqiz.cpl, or programmatically by querying the registry). Almost all software that is updated on a regular basis has a date that is within the last 2-3 months and a current version number. However, Chrome doesn't, it has the original installation date, and the current version number (per attached image). I think this is a bit of a mismatch. If I didn't know that v64.x was the current version I'd think that I have an auto-update issue. From looking at the other apps, there appear to be two major ways that organisations handle the InstallDate. They either: 1. Update the "InstallDate" registry key on every upgrade (along with the version number) which is then used in the "Installed On" column. (Apple iTunes, Oracle Java, Adobe Acrobat Reader) 2. Update the Version registry Key, BUT don't create or populate "InstallDate" key. (Mozilla Firefox, MS Office 365, Adobe Flash NPAPI) It appears that if the InstallDate is not present appwiz.cpl then relies on the last time the \Uninstall\ApplicationName key was modified for the installation date I hope this helps explain, let me know if you have any other questions. From an enterprise admin perspective Chrome seems to be an outlier by not using either of these approaches.
,
Feb 15 2018
Gentle Ping: grt@ Could you please respond to comment #5
,
Feb 22 2018
Friendly ping to get an update on this issue. Thanks..!
,
Feb 28 2018
I've provided my update, waiting on grt@ now I guess.
,
Feb 28 2018
Hi. No bisect is needed, as there has been no change in behavior. This is effectively a feature request. +blumberg, +georgesak, +afife: This sounds like a perfectly reasonable request to me. What do you think? If we make this change, should we broadcast it somehow?
,
Feb 28 2018
,
Mar 1 2018
,
Mar 1 2018
Yes, agreed it is a reasonable FR. Still a p3 compared to other work items unless folks can chime in as to the impact of not having this today.... wrt awareness: If we add this, we can announce via the release notes.
,
Mar 12 2018
As per comment #9, adding feature type
,
May 2 2018
,
May 2 2018
,
Oct 22
,
Oct 27
Here is the fix... Installation team can now get on the case with a one line coding fix. The relevant registry key is: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome I have attached an annotated Registry entry screenshot to show where the mend is. See attached file: Reg- Google Chrome Install Date 2018-10-27_15-54-02.jpg Note: Chrome Update already writes the revised version details in the registry. It will not be a major change to now also write today's date in the "InstallDate" field in the registry. I hope this helps. Raphael
,
Nov 8
,
Nov 8
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f0a7efc19e7189bfdff97a77a5596d982ea2c5b6 commit f0a7efc19e7189bfdff97a77a5596d982ea2c5b6 Author: Greg Thompson <grt@chromium.org> Date: Thu Nov 08 16:06:02 2018 Set InstallDate in the control panel to the current date on updates. This allows users and admins to see when Chrome last updated (rather than when it was originally installed) by looking in the Programs and Features control panel. This seems to be the general behavior of other apps. BUG= 807242 R=georgesak@chromium.org Change-Id: I361efba2c48a88e7b9175ecd4c24a750fa3b8562 Reviewed-on: https://chromium-review.googlesource.com/c/1326007 Reviewed-by: Georges Khalil <georgesak@chromium.org> Commit-Queue: Greg Thompson <grt@chromium.org> Cr-Commit-Position: refs/heads/master@{#606486} [modify] https://crrev.com/f0a7efc19e7189bfdff97a77a5596d982ea2c5b6/chrome/installer/setup/install_worker.cc
,
Nov 8
re: Comment 19 Author: Greg Thompson. Reviewed-by: Georges Khalil Thank you for getting on to the mod quickly. I have looked at the revised code and wonder if "Todays Date" is delivered as plain text formatted as YYYMMMDD. The relevant code line is: KEY_WOW64_32KEY, L"InstallDate", InstallUtil::GetCurrentDate(), true); Does the function GetCurrentDate() deliver plain formatted text? If so then we're good to go. I await announcement of a release date.version. See also attached graphic: Issue 807242 - is it YYYYMMDD 2018-11-08_17-38-14.jpg
,
Nov 9
Verified in today's canary.
,
Nov 13
I have tested it in Canary release overnight. It works! Good work guys. I now await arrival in the stable channel for Windows 10. =============================================================== Tested successfully against Canary 72.0.3608.4 The "installed date" does change to "Todays date" with updates. Picture evidence enclosed: "Before" & "After" screenshots of the Control Panel in Windows 10. Canary Before update 12Nov2018 2018-11-12_18-57-19.jpg Canary After update 13Nov2018 2018-11-13_06-47-49.jpg
,
Nov 14
Picture evidence enclosed: "Before" & "After" screenshots of the Control Panel in Windows 10. Canary Before update 12Nov2018 2018-11-12_18-57-19.jpg Canary After update 13Nov2018 2018-11-13_06-47-49.jpg |
|||||||||||||
►
Sign in to add a comment |
|||||||||||||
Comment 1 by manoranj...@chromium.org
, Jan 31 2018