Thanks for the report!  Definitely shouldn't be the case.  I'll investigate.

This actually turned out to be quite the rat's nest.  So, the biggest underlying problem here is that ExtensionService::ReloadExtension() *really* doesn't play nice with any extensions that previously failed to load.  And fixing that is surprisingly non-trivial.  The reason this works on the old extensions page is that we have code to monitor when an extension fails to load, and then we surface the load error.  When the user hits retry, we then go through the loadUnpacked() flow rather than the reload() flow, which doesn't hit the same snags (though could hypothetically cause other problems).

It's actually possible to get into a similarly broken state in the old UI if you reload an extension with an error, and then hit the "I give up" button - there's no way to retry the reload.  The benefit, of course, is that there's an actionable moment there, so as long as you don't hit "I give up", you can continue.

For the first version of MD extensions, I'm leaning towards achieving parity, rather than improvement, in this particular aspect.  I think we can have the reload button trigger the load failure dialog (the same as you would see for an error from load unpacked), and from there the user could retry.  The same downside will exist - if the user exits the dialog, the extension is in a broken state.  I think we can aim to address that separately, since it will be a much more involved fix.

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

commit 0a5f94495649e8abfcd0ffeedc5f28272d511bf6
Author: Devlin Cronin <rdevlin.cronin@chromium.org>
Date: Wed Dec 06 21:46:32 2017

[MD Extensions] Handle reload failures of unpacked extensions

If a user hits "reload" on an unpacked extension, there's a chance that
reload will fail (if the local files were modified in a way that causes
a load error). Once this happens, successive calls to reload() will
fail, because ExtensionService::ReloadExtension() doesn't play nicely
with extensions that failed to reload.

Adjust devleoperPrivate.reload() to return a LoadError (similar to
loadUnpacked()) if the reload fails. The extensions page now checks for
this result, and shows the load error dialog if the reload fails. The
load error dialog can then trigger a retry of this load, which goes
through loadUnpacked() rather than reload() (thus circumventing
weirdness with ExtensionService::ReloadExtension()). This is comparable
to how the current extensions page handles this scenario.

This is *not* the ideal solution, as a) we shouldn't be going through
loadUnpacked() for a loaded extension and b) the user can still get into
a broken state (where the extension cannot be enabled, nor can it be
reloaded) by dismissing the load error without fixing the error, but it
brings us at least to parity with the old page.

Bug:  789659 

Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Ib0bd6eb4bfe74b1da588a9ea78e3396703fee973
Reviewed-on: https://chromium-review.googlesource.com/798599
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522205}
[modify] https://crrev.com/0a5f94495649e8abfcd0ffeedc5f28272d511bf6/chrome/browser/extensions/api/developer_private/developer_private_api.cc
[modify] https://crrev.com/0a5f94495649e8abfcd0ffeedc5f28272d511bf6/chrome/browser/extensions/api/developer_private/developer_private_api.h
[modify] https://crrev.com/0a5f94495649e8abfcd0ffeedc5f28272d511bf6/chrome/browser/extensions/api/developer_private/developer_private_api_unittest.cc
[modify] https://crrev.com/0a5f94495649e8abfcd0ffeedc5f28272d511bf6/chrome/browser/resources/md_extensions/item.js
[modify] https://crrev.com/0a5f94495649e8abfcd0ffeedc5f28272d511bf6/chrome/browser/resources/md_extensions/manager.html
[modify] https://crrev.com/0a5f94495649e8abfcd0ffeedc5f28272d511bf6/chrome/browser/resources/md_extensions/service.js
[modify] https://crrev.com/0a5f94495649e8abfcd0ffeedc5f28272d511bf6/chrome/common/extensions/api/developer_private.idl
[modify] https://crrev.com/0a5f94495649e8abfcd0ffeedc5f28272d511bf6/chrome/test/data/webui/extensions/cr_extensions_browsertest.js
[modify] https://crrev.com/0a5f94495649e8abfcd0ffeedc5f28272d511bf6/chrome/test/data/webui/extensions/extension_item_test.js
[modify] https://crrev.com/0a5f94495649e8abfcd0ffeedc5f28272d511bf6/chrome/test/data/webui/extensions/extension_test_util.js
[modify] https://crrev.com/0a5f94495649e8abfcd0ffeedc5f28272d511bf6/chrome/test/data/webui/extensions/test_service.js
[modify] https://crrev.com/0a5f94495649e8abfcd0ffeedc5f28272d511bf6/third_party/closure_compiler/externs/developer_private.js

Should be fixed.

Please add affected OSs.

This bug requires manual review: M64 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop)

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

I'm a bit nervous about this large patch. Seems like it's a fairly large change, and affecting some fairly critical code path (developer_private_api). Why do we need this for M64? Since we are already in M64 Beta, can we wait until M65 for this?

Why it's needed: this is a blocker for MD extensions stable release, which is currently targeting M64.

As discussed in meeting, Extensions MD launch is behind a flag. Change has been tested and verified in Canary. Approving merge to M64 branch:3282

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

commit ab674692f3a853c56915e70384c730d5504f9f03
Author: dpapad <dpapad@chromium.org>
Date: Tue Dec 19 01:40:44 2017

[M64 merge] [MD Extensions] Handle reload failures of unpacked extensions

If a user hits "reload" on an unpacked extension, there's a chance that
reload will fail (if the local files were modified in a way that causes
a load error). Once this happens, successive calls to reload() will
fail, because ExtensionService::ReloadExtension() doesn't play nicely
with extensions that failed to reload.

Adjust devleoperPrivate.reload() to return a LoadError (similar to
loadUnpacked()) if the reload fails. The extensions page now checks for
this result, and shows the load error dialog if the reload fails. The
load error dialog can then trigger a retry of this load, which goes
through loadUnpacked() rather than reload() (thus circumventing
weirdness with ExtensionService::ReloadExtension()). This is comparable
to how the current extensions page handles this scenario.

This is *not* the ideal solution, as a) we shouldn't be going through
loadUnpacked() for a loaded extension and b) the user can still get into
a broken state (where the extension cannot be enabled, nor can it be
reloaded) by dismissing the load error without fixing the error, but it
brings us at least to parity with the old page.

Bug:  789659 

TBR=rdevlin.cronin@chromium.org

(cherry picked from commit 0a5f94495649e8abfcd0ffeedc5f28272d511bf6)

Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Ib0bd6eb4bfe74b1da588a9ea78e3396703fee973
Reviewed-on: https://chromium-review.googlesource.com/798599
Commit-Queue: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#522205}
Reviewed-on: https://chromium-review.googlesource.com/833234
Cr-Commit-Position: refs/branch-heads/3282@{#288}
Cr-Branched-From: 5fdc0fab22ce7efd32532ee989b223fa12f8171e-refs/heads/master@{#520840}
[modify] https://crrev.com/ab674692f3a853c56915e70384c730d5504f9f03/chrome/browser/extensions/api/developer_private/developer_private_api.cc
[modify] https://crrev.com/ab674692f3a853c56915e70384c730d5504f9f03/chrome/browser/extensions/api/developer_private/developer_private_api.h
[modify] https://crrev.com/ab674692f3a853c56915e70384c730d5504f9f03/chrome/browser/extensions/api/developer_private/developer_private_api_unittest.cc
[modify] https://crrev.com/ab674692f3a853c56915e70384c730d5504f9f03/chrome/browser/resources/md_extensions/item.js
[modify] https://crrev.com/ab674692f3a853c56915e70384c730d5504f9f03/chrome/browser/resources/md_extensions/manager.html
[modify] https://crrev.com/ab674692f3a853c56915e70384c730d5504f9f03/chrome/browser/resources/md_extensions/service.js
[modify] https://crrev.com/ab674692f3a853c56915e70384c730d5504f9f03/chrome/common/extensions/api/developer_private.idl
[modify] https://crrev.com/ab674692f3a853c56915e70384c730d5504f9f03/chrome/test/data/webui/extensions/cr_extensions_browsertest.js
[modify] https://crrev.com/ab674692f3a853c56915e70384c730d5504f9f03/chrome/test/data/webui/extensions/extension_item_test.js
[modify] https://crrev.com/ab674692f3a853c56915e70384c730d5504f9f03/chrome/test/data/webui/extensions/extension_test_util.js
[modify] https://crrev.com/ab674692f3a853c56915e70384c730d5504f9f03/chrome/test/data/webui/extensions/test_service.js
[modify] https://crrev.com/ab674692f3a853c56915e70384c730d5504f9f03/third_party/closure_compiler/externs/developer_private.js