It would also be interesting to know whether or not this corresponds to the "Set Google Chrome as Default Browser" policy setting being enabled.

Here you are the output files

Deleted: chromeversion.txt 1.5 KB

chromeversion.txt 1.5 KB View Download

and here are all the applied GPO configurations

Deleted: JPMEI002 on pcp-jpmei002.htm 1.3 MB

JPMEI002 on pcp-jpmei002.htm 1.3 MB View Download

 Issue 717944  has been merged into this issue.

TE: Could you try to reproduce this? From what I infer, repro steps should look something like:

- pick a Win7 machine
- install Chrome 57 or older from the MSI
- enable the "Set Google Chrome as Default Browser" policy setting
- confirm that the old Chrome launches without UAC prompt, and that Chrome is the default browser
- use chrome://help to update to Chrome 58
- relaunch and check for UAC prompt

Anyone experiencing this: please fill in any additional details. Is anything missing from these repro steps? Are you able to reproduce it on a fairly clean machine?

Tested this issue on Skytap "Windows GPO Testing - Stable - K" environment.

These are the steps followed.


1. Installed Chrome 57.0.2987.133 on Windows 7 through group policy editor
2. Enabled the "Set Google Chrome as Default Browser" policy setting
3. Confirmed that the old Chrome launches without UAC prompt and that Chrome is the default 
   browser in Windows 7 Machine.
4. Updated chrome to 58.0.3029.96 using chrome://help 
5. Restarted the chrome.

Didn't observe any UAC prompt while launching the M58 chrome browser.

I'm trying to reproduce this issue, please point me to a Chrome MSI repository where I can download older versions.
Thanks.

Thanks for your help. Google doesn't maintain a public repository of older versions, so you'll have to try to find one elsewhere on the interwebs. Be sure to check the signature on one you find to be sure it hasn't been tampered with.

Here you will find registry queries and chrome version output grabbed from a test VM affected with this issue.

Deleted: chromeversion(quo).txt 1.4 KB

chromeversion(quo).txt 1.4 KB View Download

Deleted: chromereg(quo).txt 4.2 KB

chromereg(quo).txt 4.2 KB View Download

Thanks for those log files. Nothing jumps out at me. Have you been able to get a clean machine into this state? I don't suppose you can grant me access to use RDP to connect to this VM, can you? I should be able to figure out what's going on given a machine exhibiting the problem and windbg.

Has anyone been able to find a fix or workaround for this yet?

I was able to reproduce the issue in our environment, the issue owner is debugging it.
Are you asking because it happens to you too?

Yes it happens on my network. I started the topic (second link) at the top of this bug report. I can't find anything to cause it at the moment but its a real nuisance at the moment.

Whew! This one took a while to get to the bottom of.

This is a case of a fix to a bug uncovering a different bug. :-( In r452624, I fixed a bug with the code that is making this UAC prompt appear. As it happens, ElevateAndRegisterChrome had never worked for MSI installs. I noticed this while making other code changes. Fixing it seemed like a good thing at the time.

However, it seems that the population of users impacted by that fix overlaps very well with enterprises, because now that UAC dialog will pop under the following conditions:

- Win7 (Win8+ don't suffer from this).
- "Set Google Chrome as Default Browser" policy setting is true.
- The locale used by Chrome doesn't match the one used by the installer (e.g., due to the "Application locale" policy setting).

In the specific case I investigated, the installer runs with locale "en" when it writes values into the registry, yet Chrome itself is using "en_GB" based on the policy setting. Due to the language mismatch (related to issue 75152), Chrome thinks its registration in HKLM is missing/broken, so it asks the user to elevate so it can fix this. In M57 and below, this elevation path was broken so nothing happened.

It doesn't make sense for Chrome to think its registration is bad when only the locale has changed. I've updated the summary for this issue accordingly.

In the meantime, you can workaround this by either setting the "Application locale" policy to "en" or by disabling the "Set Google Chrome as Default Browser" setting until we have a fix.

Excellent work!

I confirm the workaround - setting the "Application locale" policy to "en" from en-GB has fixed this issue for me.

Thank you for your work and for taking our report seriously from the very beginning.

I'm trying to understand if I can use the proposed workarounds. 

About default browser: I need to be sure new users are using Chrome and not IE so it's not an option.
About application locale: we forced en_GB mainly to avoid US date and time formats while browsing but googling around now it seems to me that this option is mainly use to set default spell checking. 
If it's only just about spell checking (the difference between en and en_GB) maybe we can use this workaround.

Can you guess an ETA to have a fix for this issue in the stable version? (maybe we can just wait without applying workarounds) 
Does this issue affects the Chrome automatic update feature?

Rather than setting Chrome's lang to en_GB via policy, could you instead set a policy to make the OS locale en_GB? This should be picked up by both Chrome's installer and by Chrome. The key is having the two in sync, not necessarily forcing "en" for Chrome's lang.

Alternatively, update to Win10. :-)

As for timing a fix, I'm not certain when it will happen. I'll followup when I know more.

gab@: the bug here is that IsChromeRegistered looks for string matches when doing its checks. Chrome's locale may not match that of setup.exe's when the install-time registration was done, so some values may not match. One fix would be to change the probing done by AreEntriesAsDesired so that it doesn't require the values to match for the various things that are locale-dependent. What do you think?

ElevateAndRegisterChrome should only be required for user-level installs on Win7, no? It's because Win7 requires registrations in HKLM to be considered as an app that supports HTTP/etc. even for a single user (Win8+ allows HKCU registrations and that's what we use there).

Currently ElevateAndRegisterChrome() tries to fix things up in HKLM regardless of install state if it notices something missing/broken (wrong locale would sure do it). Maybe it should assume the state is fine and only check if it needs extra state in user-level installs? Or maybe it should check for the presence of keys without verifying their value? The goal is merely to ask the question "is Chrome registered for HTTP/etc. as it should be but won't be on a user-level install being made default for the first time?"

If it's meant for only user-level installs, then it's a simple thing to make that so. Changing that will shrink the problem to the point where the bug probably won't matter (Win7, per-user install, app locale doesn't match UI locale, and a policy setting says that Chrome should be the default browser -- highly unlikely).

Well it's also meant for "fix broken HKLM regs so that user doesn't get in infinite loop of not being able to set default"... but I'll leave it up to you to decide whether you want to keep supporting that.

It's required for user-level + Win7, it's nice-to-have for system-level repair (but then it's not being nice here... and the installer will always repair next update so...).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/31546fb25253afc574bf366d92ef20790c7d418c

commit 31546fb25253afc574bf366d92ef20790c7d418c
Author: grt <grt@chromium.org>
Date: Thu May 18 09:19:59 2017

Do not elevate to register Chrome for system-level Win7 installs.

On Windows 7, browsers must be registered with the OS in HKLM. Chrome's
installer takes care of this during install/update for system-level
installs. For user-level installs, however, Chrome must pop a UAC prompt
to have setup.exe run at high integrity for this registration.

This change suppresses the elevate-to-register codepath for system-level
installs on Windows 7 since this is the installer's responsibility. This
prevents over-prompting some users (see the bug for details) at the risk
of not prompting users for whom Chrome truly isn't registered. If those
users are running a properly updating Chrome, its registration will be
repaired on the next update. If they are not running an updating Chrome,
they have bigger problems.

BUG= 717913 
R=gab@chromium.org

Review-Url: https://codereview.chromium.org/2878953003
Cr-Commit-Position: refs/heads/master@{#472750}

[modify] https://crrev.com/31546fb25253afc574bf366d92ef20790c7d418c/chrome/installer/util/shell_util.cc

I'll request a merge to M59 once I've verified this with an official build.

I would like to asked for an update regarding this bug? I do have a customer that is having this problem, Can i know when will this be fix or version 59 will fix this bug?

Verified with 60.0.3109.0 on a Win7 VM that exhibited the problem.

Requesting a merge to M59 so that we can relieve admin pain sooner. Thanks.

This bug requires manual review: We are only 12 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), gkihumba@(ChromeOS), Abdul Syed@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

hi grt@ - can you please confirm if this is an overall safe merge, and is there enough automated test coverage for this? What are the implications of waiting until M60? We're moving to M59 stable next week.

I think it's a safe merge based on my manual testing. The downside to waiting for M60 is that admins will continue to have trouble with their fleet when they have things configured for Chrome to be users' default browser. Based on the traffic on this bug and in the admin forum, I think this regression is problematic for admins. +blumberg to weigh in.

+gab in case he has concerns regarding the risk of merging.

Thanks for taking this into consideration.

It's a safe merge (confirmed in comment 30), tested (comment 27), and based on product forums, it's causing pain to admins, approving it for M59. 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bf573c90784bf148baf921734b2f48eb660b37a8

commit bf573c90784bf148baf921734b2f48eb660b37a8
Author: Greg Thompson <grt@chromium.org>
Date: Fri May 26 20:41:04 2017

Do not elevate to register Chrome for system-level Win7 installs.

On Windows 7, browsers must be registered with the OS in HKLM. Chrome's
installer takes care of this during install/update for system-level
installs. For user-level installs, however, Chrome must pop a UAC prompt
to have setup.exe run at high integrity for this registration.

This change suppresses the elevate-to-register codepath for system-level
installs on Windows 7 since this is the installer's responsibility. This
prevents over-prompting some users (see the bug for details) at the risk
of not prompting users for whom Chrome truly isn't registered. If those
users are running a properly updating Chrome, its registration will be
repaired on the next update. If they are not running an updating Chrome,
they have bigger problems.

BUG= 717913 
R=gab@chromium.org

Review-Url: https://codereview.chromium.org/2878953003
Cr-Original-Commit-Position: refs/heads/master@{#472750}
Review-Url: https://codereview.chromium.org/2910743002 .
Cr-Commit-Position: refs/branch-heads/3071@{#706}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

[modify] https://crrev.com/bf573c90784bf148baf921734b2f48eb660b37a8/chrome/installer/util/shell_util.cc

Vérification steps:
Set up a win 7 box and use gpedit.msc to set the default browser policy setting to enabled and the application locale setting to en_gb (or en-gb, I forget which). Now install and launch M58. It should throw a UAC prompt at browser launch. Update to M59 and there should be no UAC.

FYI to those impacted by this issue: the fix is in the current stable release. Cheers.

Thank you Greg!

Still happened in our org with a deployment from 56 or 58 to version 59. Has not occurred before. 

https://productforums.google.com/forum/#!topic/chrome-admins/GuNA0vp_wec;context-place=forum/chrome-admins

Please assist as we need to deploy it to a couple of thousand