Thanks for filing the issue!

Able to reproduce the issue on reported chrome version 65.0.3325.162 and on the latest canary 67.0.3396.0 using Windows 10, Ubuntu 14.04 and Mac 10.13.1.
Note: Unable to add the extension on any of the chrome versions across mentioned OS platforms. Considering this as an issue, as this behaviour is seen from M60(60.0.3072.0) considering it as Non-Regression and marking it as Untriaged.

What's the install flow like for the docs extension?  Can you give more details on what happens in step 4/5?

What I'm wondering is: is the issue here that we don't treat corruption properly and instead offer to install the extension, or is it that the (re)installation of the extension doesn't result in it becoming un-corrupted?

Devlin,

In order to perform a copy/paste via the right-click context menu we need clipboard read/write perms and these come via the offline extension.  In step 4 if you try to perform a copy (without clipboard perms) you are prompted to install the extension.  In step 5 if you click install (on the prompt) we try to inline install the extension, that inline install of the extension doesn't result in it becoming un-corrupted.

TLDR Issue is just that the reinstall doesn't un-corrupt the extension

It seems running inline installation for a corrupt extension is only trying to enabling the extension.

For this particular extension, I deliberately corrupted the background script that turn into corrupted state, then inline installing just enabled the extension with the file still retaining the state.

Devlin, maybe inline installation code is discovering the extension exists in registry and is simply trying ot reenable it?

Is this behaving as expected or should the inline install un-corrupt the extension?

We never had inline install hooked up to repair a corrupt extension, so there's no expectation that the extension be repaired.  Theoretically we could, but it's not really on our road map for the time being.  If someone else wanted to take this on, we're happy to assist with guidance/reviews.

Devlin,

I may pick this up time permitting, ballpark what do you think the effort for this would be?

Also, installs from the web store don't repair corrupted extensions either, should that be the case as well?  When I was assisting the user that reported this it wasn't immediately clear to either of us that the extension was corrupted, to docs it appeared as though it wasn't installed and as mentioned inline installs and redirects to the web store (so she could install) failed to fix.  Should we have been trying to detect differently or is there even a way to detect within an app that an extension is corrupt?

Also, could someone instruct me on how to repro the corruption so I can test locally?

Thanks

> Also, could someone instruct me on how to repro the corruption so I can test locally?

If you modify any of the extension's javascript files on your local machine (in %user_data_dir%(1)/%profile%/extensions/%extension_id%/%extension_version%), the extension should be marked as corrupted when that resource is loaded by the extension. For quicker testing, I recommend modifying a script file listed as a background script or content script in the extension's manifest. 

(1) See https://chromium.googlesource.com/chromium/src/+/master/docs/user_data_dir.md for user-data-dir

> I may pick this up time permitting, ballpark what do you think the effort for this would be?

This depends a bit on how much we care about the UX here.  Conceptually, what we'd want at minimum is, when the user says "install", to instead first check if the extension is present and corrupt, and, if it is, repair it.  This by itself shouldn't be terribly difficult.

However, that's a pretty unusual UX in general (going through an installation flow for an extension that's already present).  As "slightly better", we have a repair prompt that we could display instead of the normal install prompt.  This makes things a little nicer, but still not great.  I think best here would be to also have the webstore have a different string for corrupted extensions, similar to the "launch app" button that's there for an installed app.  This would be great, but would involve both Chrome side and webstore side changes.

Personally, I don't have a strong preference - I think the current version is very odd, so "slightly less odd, but still very odd" is potentially worth it. :) +James, in case he has thoughts on that.

> Also, installs from the web store don't repair corrupted extensions either, should that be the case as well?

Ideally, yes.

> Should we have been trying to detect differently or is there even a way to detect within an app that an extension is corrupt?

Not currently, no.  There potentially could be, but it would be a little complicated (we don't always want to expose otherwise-disabled extensions presence to sites, and we'd need to make sure it's only exposed to cooperating sites - though externally connectable should work well for this).

+jawag@ for real.

+markchang@ for input on CWS strings.

When mcleane@ gets the eng work done, let's get the string to be "Repair" instead of "Install".