I've come up with a doc showing some of the possible transitions that cause duplicate notifications like this. See the table linked from here: http://go/phbin

ExtensionSystem::UnregisterExtensionWithRequestContexts can also be called multiple times, with different "unload" reasons. If the extension was already disabled/terminated (and hasn't been uninstalled yet) then it's a no-op, so it appears safe to omit this call in that case.

https://cs.chromium.org/chromium/src/extensions/browser/info_map.cc?type=cs&l=84

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

commit f94979b198ec5b1cac7391d2854f62d4b712fbbe
Author: Michael Giuffrida <michaelpg@chromium.org>
Date: Wed Dec 20 21:14:56 2017

Don't send NOTIFICATION_EXTENSION_REMOVED when terminating extension

This notification seems to be intended to announce when an extension is
being removed from the system, but is sent for unknown reasons when an
extension is being terminated.

The notification is observed in 3 places (outside of tests):
- ExternalInstallManager: Doesn't warn about enabled extensions, so it
  doesn't need to observe extensions being terminated.
- ExtensionDisabledGlobalError: Unnecessary here for the same reason.
- IconImage: The notification causes this class to clear its extension_
  reference, so it won't be able to fetch resources in the future. I've
  found no reason why this or its subclasses should want to do this when
  an extension is terminated -- we still show the extension's icon until
  it's removed from the system.

So I think it's safe to remove this special case. We should only fire
NOTIFICATION_EXTENSION_REMOVED when an extension is removed.

Bug: 708230
Change-Id: Id23a2673a2e3465eeb19c3e67dba87c5b7add1c6
Reviewed-on: https://chromium-review.googlesource.com/832520
Commit-Queue: Michael Giuffrida <michaelpg@chromium.org>
Reviewed-by: Devlin <rdevlin.cronin@chromium.org>
Reviewed-by: Karan Bhatia <karandeepb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525456}
[modify] https://crrev.com/f94979b198ec5b1cac7391d2854f62d4b712fbbe/extensions/browser/extension_registrar.cc
[modify] https://crrev.com/f94979b198ec5b1cac7391d2854f62d4b712fbbe/extensions/browser/extension_registrar_unittest.cc

I didn't realize we created a new Extension object for every extension in every renderer process. Is that WAI? It seems a bit wasteful to create Extension new objects for each renderer, since most extensions don't need to interact with most renderers AFAIK.

Furthermore these Extension objects aren't ever freed. Does that warrant further investigation?

So, in the browser, extensions are refcounted, and we don't create new ones per-renderer - they all point to the same object.  In the renderer, the objects are kept around for the lifetime of the process or until the extension is removed.  That's WAI.

Ideally, we'd be able to trim some more of this information, but it's not always easy.  There's a number of things that we might need access to renderer-side - a top-of-mind example is web accessible resources.  We could do a better job of potentially limiting which extensions we send (or which information about them we send), and it's something we'd like to do, but hasn't been prioritized.

Is there a reason this seems overly wasteful in the bigger scheme of things?  Extension objects are large, but shouldn't (normally) be huge, so keeping a copy per-process doesn't seem too egregious.