Adding release blocker label for this issue.Please reduce priority or remove if not the case.

Thank You!

The toast is correct as far as I can tell. Before the "Updating..." toast would auto-hide after a fixed duration has elapsed after it was shown. This was changed to show the "Updating..." toast indefinitely until the update for all the extensions completed (due to an failed or successful update attempt).

The update is currently in progress. Even though the UI is not showing any extensions, there are extensions that are parts of chrome that are not shown in the extensions UI (for example one of them is the pdf viewer).

I can replicate this by adding the following to /etc/hosts:

127.0.0.1       clients2.google.com

The fix does not belong in the UI. What should we do in this case? Should or does the extension download timeout after some point? Should this still be considered a blocker?

I don't think this is worth blocking Stable. A potential UI fix would be to disable the "Update" button if there are no user-visible extensions (ignoring extensions that are not shown in the UI).

@rdevlin.cronin: Thoughts?

I think it's worth targeting M67 for this, given how early we are in the cycle and that this is a regression.

Hiding the update button seems reasonable from a UX perspective (since it isn't very logical if there's nothing there), but I'm also curious why this fails with no extensions.  What logic is the toast using for when to show/hide?  Is it indicative of a larger problem somewhere that could surface in other circumstances?

The UI is depending on the update completing in some way (success or error). When  "clients2.google.com" is blocked, the update never completes. Disabling the update button would not have the desired effect. If the intention is to only update the visible extensions, we'll also need to add a parameter to ExtensionUpdater::CheckNow that will filter out extensions that are not visible.

Is it is a problem to update all extensions, instead of just the ones that are visible? This is what already happens anyway, no?

Basically proposing the following. Before:
 - "Update" triggers updating of all extensions.
 - "Update" always visible, even when no extensions are shown to the user.

After:
  - "Update" triggers updating of all extensions.
  - "Update" visible only when at least one extensions is surfaced to the user.

AFAIK, Chrome already updates all extensions periodically, so we would not be accidentally forcing any users to update non third-party extensions anyway, as a result of this change.

> the update never completes

Sorry, missed that in my previous response. Yes, that seems like separate issue that can happen even when extensions are surfaced to the user, right? In that case, not exactly what the original report describes? Should we file this separately maybe? 

Right, this has nothing to do with how many extensions are visible or user-installed. We can either file separately, or determine what the underlying problem is and fix that.

I think this is likely a firewall issue. The download operation also never seems to fail. If I'm reading what's happening correctly, the requests retry with an exponential backoff, and there is no timeout or max retries.

@dpapad and @rdevlin.cronin: Would it make sense to consider introducing a timeout or max retries and if there is a failure show an update failed toast and/or errors in the extension cards?

I think a timeout makes sense.  Surfacing it as an error could be interesting, but I don't know if it's worth the investment.

I just looked into this again. I can no longer replicate the issue even with blocking "clients2.google.com". Something has changed, so I'm not sure this is still an issue. 

I found a max retries of 10 which will callback with an error after about 34 minutes. We can change the max retries to something lower or pass in a lower max retries in certain cases.

https://cs.chromium.org/chromium/src/extensions/browser/updater/extension_downloader.h?type=cs&q=kMaxRetries&sq=package:chromium&l=141

In summary, the toast was surfacing an underlying issue with updating component extensions. And now it looks like the component extensions are no longer being updated in this situation. For that reason, I'm going to close this.