Re-enabling the extension explicitly via chrome://extensions, it is re-disabled as soon as you refresh that page.

Devlin, how does one find out why a Chrome App is greyed-out...?

Where are you seeing it greyed out?

Looking for the entry in chrome://prefs-internals would be useful.  It should have information about e.g. disabled reasons, etc.

Re #3: This is in the chrome://apps view, and it is also shown as disabled in chrome://extensions.

"disabled_reasons" for the app is 65536, which appears to be "blocked by policy"?

Interesting.  This was added by isandrk in revision 4a55dc2f10c67667256a7c28a82ead57287e0ef3.  Assigning to him to investigate.

+nrpeter@, wfh@ since this might be related to internal b/117570967.

also see issue 894184

Re #6: This sounds like exactly the same issue; let's either de-dupe into your bug (since this is a sub-set of what you saw) or use this for greying-out and the other for removal?  My guess, though, would be that it's the same root-cause, some uninitialized or garbage value being handled somewhere. :(

I'm away from my workstation so cannot do a full analysis.  However, I found out there's only two places in the code that set the DISABLE_BLOCKED_BY_POLICY value:
- ManagementPolicy::MustRemainDisabled [1]
- ManagementSetEnabledFunction::Run [2]

If it's the second one, it's possible that a rogue force-installed or component extension is disabling other extensions.

For the first one, I'm not sure what that means.  Possible that it comes down to ExtensionManagement::GetBlockedAPIPermissions [3], which does stuff like the following:
  // Fetch per-extension blocked permissions setting.
  // Fetch per-update-url blocked permissions setting.
  // Fall back to the default blocked permissions setting.

-> Possible that something was changed there?


[1] https://chromium.googlesource.com/chromium/src/+/b0e3983f7a7a814c285c2302b16ffd345ba37815/extensions/browser/management_policy.cc#118
[2] https://chromium.googlesource.com/chromium/src/+/b0e3983f7a7a814c285c2302b16ffd345ba37815/extensions/browser/api/management/management_api.cc#480
[3] https://chromium.googlesource.com/chromium/src/+/a563e29ee53b9b2f5e8a35da7c52f96310636a02/chrome/browser/extensions/extension_management.cc#170

Tentatively merging bugs, feel free to re-open.

I'll re-open this one for now as we might have more luck here.

Wez, could you instrument locations [1] & [2] from my comment #9 and see where the DISABLE_BLOCKED_BY_POLICY is coming from?  That would help a lot in finding the root cause.  I cannot reproduce this, so my hands are really tied.

Anyway, I think someone from the extensions team would do a better job at investigating this one than me (they might have access to Windows workstations, and might just walk up to someone having problems with this).

I'm confused, there seem to be two bugs but the root cause is very likely the same. I've provided info in 894184. Can we

1. Merge the bugs or decide which one we are tracking.
2. Make sure it's release block stable
3. Find someone to work on it?

I don't think 3. should be wez or me, I'm happy to provide additional details as requested (and have done so in issue 894184) but there needs to be some reciprocation from whichever team owns this code.

The two extensions that are reported as being greyed-out are CRD and the Secure Shell app. These are both apps that I've had installed in my profile for years.

I tried copying my profile and then running a locally-built Google Chrome binary against that and initially CRD was greyed-out, but then suddenly it became enabled; I've no idea what triggered that, though.

+nigeltao@, who I notice is the person who updated the comment on Manifest::Location::INTERNAL, which came up on issue 894184.

My guess would be that the CRD extension should be tagged with Location::EXTERNAL_POLICY, because it is force-installed via Windows policy, but it was instead tagged with Location::INTERNAL because it is a default-installed extension on ChromeOS.

So are we mistakenly Sync'ing the extension Location from ChromeOS->Windows?

Re-tagging as a duplicate of 894184 since that seems most likely.